google
Search for other free cores when bind fails
Edit:
I just noticed this is quite similar to #63... coincidence! How should we handle this? Looks like #63 can be rebased on top of mine to add #ifdef ANDROID bits for inverting the search order and drop the rest? @JoeyJiao thoughts?
Under some circumstances, /proc may transparently lie to us, or we may have cgroups invisibly that prevent us from binding to certain CPUs but not others. In particular this shows up when running inside containers with resource limits applied to them. This patch makes AFL continue to try other CPU cores if the kernel rejects our attempt to bind to an apparently free one, since others may succeed.
At first I wasn't sure this patch belonged in AFL, but since AFL generally tries to be smart about its environment when it helps the user, and this is a realistic case that AFL can solve itself without much overhead, I think it's appropriate.
I put some more details on how/why this manifests here: https://gist.github.com/qlyoung/abd217f977399003ba0cc277feca2af9
Here's how it looks after this patch when running in a Docker container with --cpuset-cpus 5,6:
afl-fuzz 2.56b by <[email protected]>
[+] You have 8 CPU cores and 4 runnable tasks (utilization: 50%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, attempting bind to #0.
[!] WARNING: Binding attempt failed; looking for another core...
[+] Found a free CPU core, attempting bind to #1.
[!] WARNING: Binding attempt failed; looking for another core...
[+] Found a free CPU core, attempting bind to #2.
[!] WARNING: Binding attempt failed; looking for another core...
[+] Found a free CPU core, attempting bind to #3.
[!] WARNING: Binding attempt failed; looking for another core...
[+] Found a free CPU core, attempting bind to #4.
[!] WARNING: Binding attempt failed; looking for another core...
[+] Found a free CPU core, attempting bind to #5.
[*] Checking core_pattern...
[*] Checking CPU scaling governor...
...
AFL continues as normal after that. Prior to this patch it simply aborted on a failed sched_setaffinity.
Signed-off-by: Quentin Young [email protected]
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.
What to do if you already signed the CLA
Individual signers
- It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
Corporate signers
- Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
- The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
- The email used to register you as an authorized contributor must also be attached to your GitHub account.
ℹ️ Googlers: Go here for more info.
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.
What to do if you already signed the CLA
Individual signers
- It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
Corporate signers
- Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
- The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
- The email used to register you as an authorized contributor must also be attached to your GitHub account.
ℹ️ Googlers: Go here for more info.
@qlyoung yes, they are similar but #63 has more change I think For most android devices, cpu#0-3 is less power than cpu#4-7, so #63 prefers cpu#7 as the first candidate. For intel platform, start from cpu#0 is better.
@JoeyJiao yeah I'd like to use your search method since that works for Android too, and I'd also like to keep my error messages / suggestions since they work for both android and my particular scenario, so I was thinking you could rebase on top of my commit to change the search algorithm in my patch to yours and we could merge the 2 commits, that seems like the cleanest resultant history and we both keep authorship.
Of course I could also rebase mine onto yours but my diff is bigger so it seemed easier to do it the other way round.