-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firefox #1546
firefox #1546
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rough first-cut review.
Thanks for working on this! This is pretty exciting.
projects/firefox/build.sh
Outdated
# Build a wrapper binary for each target to set environment variables. | ||
for FUZZ_TARGET in ${FUZZ_TARGETS[@]} | ||
do | ||
cat << EOF > $FUZZ_TARGET.c |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put this is a normal C file and use defines to include the various compile-time parameters
projects/firefox/build.sh
Outdated
// Temporary (or permanent?) work-around for a bug in the fuzzing interface. | ||
// https://bugzilla.mozilla.org/show_bug.cgi?id=1466021#c9 | ||
char* options = getenv("ASAN_OPTIONS"); | ||
strcat(options, ":detect_stack_use_after_return=0"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is safe at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I'm surprised now that it even works. Probably overwrites an unimportant variable name.
projects/firefox/project.yaml
Outdated
homepage: "https://www.mozilla.org/firefox/" | ||
primary_contact: "agaynor@mozilla.com" | ||
fuzzing_engines: | ||
- none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is right, probably should be libFuzzer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True.
projects/firefox/project.yaml
Outdated
fuzzing_engines: | ||
- none | ||
sanitizers: | ||
- address |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a minimum we also want @choller in the CCs, probably some other folks as well
I'll address the points in an updated PR, but I'd also like an opinion of a Googler on the general approach. |
Please take a look. I noticed from the build logs that it builds on 32 vCPU instances, so I updated the timings for that. With code downloading, it produces target binaries in 30-35 minutes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems OK, with the caveat that since this is kind of unsupported it may break at any time on our production infrastructure. Are there any long term plans to better break up firefox's targets?
Also, please test this with the run_minijail
script in the base-runner image like so:
$ run_minijail /out/target_name
To make sure things still work under minijail.
projects/firefox/target.c
Outdated
perror("LD_LIBRARY_PATH unexpectedly set"); | ||
exit(1); | ||
} | ||
if (setenv("LD_LIBRARY_PATH", STRINGIFY(LIB_PATH), 0)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this dynamic based on the cwd and argv[0]? the binaries are not guaranteed to be executed from the same $OUT. Alternatively, patch rpaths using $ORIGIN.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
projects/firefox/target.c
Outdated
} | ||
free(new_options); | ||
|
||
return execv(STRINGIFY(FIREFOX_BINARY), argv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, the binaries won't always be in $OUT.
projects/firefox/build.sh
Outdated
# These are taken from running ldd on libraries build for Firefox, with the | ||
# output manually filtered for libraries which are available on base-runner. | ||
# Patching even some libraries out doesn't work (undefined symbol errors). | ||
REQUIRED_LIBRARIES=( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can these be statically linked in somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we discussed this before. It is not easily possible to link some system level dependencies statically.
No. Breaking up the Firefox build process would require massive architectural changes in the project itself and that is currently not on the Firefox engineering agenda and probably won't be any time soon. |
I hadn't tried |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can give this a shot now, if run_minijail works.
Are there any more comments from firefox folks? Once again this is a rather unsupported way of doing things and may break frequently.
In the long run to better support this, I think we need some way to let projects specify their own dependencies in the runner, and unify the OSS-Fuzz runner image with our actual runner images used on ClusterFuzz.
Where do you identify the likely breaking points? If it's the many required shared libraries potentially changing frequently, then the good news is that this can actually be automated quite nicely. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small comment, otherwise LGTM. Will be interesting to see the results!
projects/firefox/build.sh
Outdated
|
||
# Case-sensitive names of internal Firefox fuzzing targets. Edit to add more. | ||
FUZZ_TARGETS=( | ||
ContentParentIPC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove this one for now -- as we discussed on the Firefox bug tracker, running the IPC fuzzer requires a few other env vars, otherwise we get a bunch of uninteresting crashes. We should add this back soon, but let's get the initial PR landed and then circle back.
It seems (from the public build logs) the first build failed with a network error. Bad luck. |
* firefox * make wrapper its own file * many minor changes * build package rather then copying * add (disabled) Qcms target * getenv doesn't use errno * make paths dynamically * minor find fix * handle absolute path * make run_minijail work * get required libraries automatically * Remove ContentParentIPC fuzz target
This is a preliminary PR for comments and discussion. It's complete, except for a bit of error handling. Read #1462 for previous discussion. The targets work locally with
run_fuzzer
.I initially tried to tackle the problem with the many required libraries by using
patchelf
. Worked for some at first, or so it seemed, but those dependencies came back through other libraries. Since many libraries were going to be required anyway, I went for this single approach, rather than perhaps patching a few libraries out in addition to that.It's lacking corpus and dictionary handling, which is trivial to add. I didn't make any, because I'm not familiar with the formats. Those would be hosted in
mozilla-central
anyway. If they already are, I couldn't find them.