Skip to content
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

Merged
merged 12 commits into from
Jul 25, 2018
Merged

firefox #1546

merged 12 commits into from
Jul 25, 2018

Conversation

pdknsk
Copy link
Contributor

@pdknsk pdknsk commented Jun 21, 2018

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.

@pdknsk pdknsk mentioned this pull request Jun 21, 2018
Copy link
Contributor

@alex alex left a 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.

# Build a wrapper binary for each target to set environment variables.
for FUZZ_TARGET in ${FUZZ_TARGETS[@]}
do
cat << EOF > $FUZZ_TARGET.c
Copy link
Contributor

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

// 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");
Copy link
Contributor

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

Copy link
Contributor Author

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.

homepage: "https://www.mozilla.org/firefox/"
primary_contact: "agaynor@mozilla.com"
fuzzing_engines:
- none
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True.

fuzzing_engines:
- none
sanitizers:
- address
Copy link
Contributor

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

@pdknsk
Copy link
Contributor Author

pdknsk commented Jun 25, 2018

I'll address the points in an updated PR, but I'd also like an opinion of a Googler on the general approach.

@pdknsk
Copy link
Contributor Author

pdknsk commented Jul 5, 2018

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.

Copy link
Collaborator

@oliverchang oliverchang left a 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.

perror("LD_LIBRARY_PATH unexpectedly set");
exit(1);
}
if (setenv("LD_LIBRARY_PATH", STRINGIFY(LIB_PATH), 0)) {
Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

}
free(new_options);

return execv(STRINGIFY(FIREFOX_BINARY), argv);
Copy link
Collaborator

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.

# 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=(
Copy link
Collaborator

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?

Copy link
Contributor

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.

@choller
Copy link
Contributor

choller commented Jul 9, 2018

Are there any long term plans to better break up firefox's targets?

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.

@pdknsk
Copy link
Contributor Author

pdknsk commented Jul 13, 2018

I hadn't tried run_minijail because I had assumed run_fuzzer calls it internally. Works now.

Copy link
Collaborator

@oliverchang oliverchang left a 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.

@pdknsk
Copy link
Contributor Author

pdknsk commented Jul 20, 2018

Once again this is a rather unsupported way of doing things and may break frequently.

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.

Copy link
Contributor

@alex alex left a 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!


# Case-sensitive names of internal Firefox fuzzing targets. Edit to add more.
FUZZ_TARGETS=(
ContentParentIPC
Copy link
Contributor

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.

@inferno-chromium inferno-chromium merged commit d96443b into google:master Jul 25, 2018
@pdknsk
Copy link
Contributor Author

pdknsk commented Jul 26, 2018

It seems (from the public build logs) the first build failed with a network error. Bad luck.

@pdknsk pdknsk deleted the firefox branch July 26, 2018 07:04
tmatth pushed a commit to tmatth/oss-fuzz that referenced this pull request Oct 22, 2018
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants