firefox micro-targets #1462
Comments
|
Sounds similar to what we discussed with @choller recently... |
|
And answering another part of the question: |
|
Yes, Firefox's current libFuzzer integration still builds all of libxul.so
(aka basically everything). Doing better than this would require a
significant change to our build system AFAIK.
…On Wed, May 30, 2018 at 7:03 PM Kostya Serebryany ***@***.***> wrote:
And answering another part of the question:
I think that any code that is part of the Firefox is within the scope of
oss-fuzz.
From out previous discussion with @choller <https://github.com/choller>
there might be some challenges making it scale
(e.g. it might be hard to actually have small binaries for every target).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1462 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAADBAP65lMD084xmuDjS7cdfv3T4Stjks5t3yVKgaJpZM4UUGyG>
.
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
|
|
Yes, we discussed this before, and this is actually the interface I've been mentioning in our meetings. We are also about to land some additional targets in our codebase, in addition to what we have now already. They should all be coverable with a single build. Our build system does partial instrumentation automatically when building a fuzzing build (it adds the libfuzzer flags only in places where we actually have fuzzing targets). If you want to incorporate any of the targets into oss-fuzz, I'll be glad to give some pointers. |
|
It is also correct that we build all of libxul and can't build smaller targets, yes. But how does that stop you from scaling it, if the same build can be used for multiple targets? |
Maybe it doesn't, I am not sure. Anyway, looking forward to adding more Mozilla's fuzz targets :) |
|
I thought about this when I ported It seems like the best approach for this would be to have a FUZZER=name path/to/firefoxSo either separate binaries for each fuzz target with the variable somehow hard-coded would need to be made, or |
|
That's correct. I don't know how well that matches the OSS-Fuzz's teams
vision, it's obviously a bit different from the standard integration.
…On Wed, May 30, 2018 at 8:13 PM pdknsk ***@***.***> wrote:
I thought about this when I ported qcms to the native fuzzing interface.
(That's a separate discussion I'll move to its bug on the Firefox tracker.)
It seems like the best approach for this would be to have a firefox
project, that builds select native targets. Since oss-fuzz seems to
attempt to run any binary it finds in $OUT I think this should just work.
Or wait, the fuzz target is selected with an environment variable.
FUZZER=name path/to/firefox
So either separate binaries for each fuzz target with the variable somehow
hard-coded would need to be made, or oss-fuzz told to run the same binary
with different environment variables. Is this right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1462 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAADBJ7kRlD-ixD9HWJAZ7KOY9E_U5Wuks5t3zWkgaJpZM4UUGyG>
.
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
|
|
These will need to be separate binaries, we don't deal with any env vars. |
|
The firefox fuzzing interface heavily relies on environment variables and you cannot just link another binary to libxul.so. The building/linking is complicated and I strongly suggest to use the same binary + libxul.so package for all targets, then use environment variables to configure. If really necessary, you might be able to build wrapper binaries that exec() to the real binary after setting the environment variables, but that's really a hack then. |
|
In LLVM we use another hack: we build a single binary, and then copy it to several different onces that have different names, and based on the name of the executable we choose what to fuzz. |
|
You cannot do this in Firefox either with the way to fuzzing system is built. We do not simply link to libxul and call a libfuzzer main, but we do initialization work that has to be done first, then call back to our own libfuzzer main that uses a registry of fuzzing targets. Environment variables are used twice along the way at least, eliminating those will be hard. Why is setting env vars inside a dummy binary (hard coded) and then using execvpe() a no-go? |
There may be other reasons, but this seems like it will definitely break AFL |
Yes, I only had libFuzzer in mind here which would already be a good start. |
|
If this work with libFuzzer for you it may work with libFuzzer for oss-fuzz, |
|
Yes, but that was a given anyway. The current scope of |
|
Let's try. |
|
I think this will work. Using thin wrapper-binaries that call |
|
Per our conversation today, here's what a stub binary might look like: #define STRINGIFY_X(v) #v
#define STRINGIFY(v) STRINGIFY_X(v)
int main(int argc, char* argv[]) {
if (setenv("MOZ_RUN_GTEST", "1", 1) ||
setenv("LIBFUZZER", "1", 1) ||
setenv("FUZZER", STRINGIFY(FIREFOX_FUZZ_TARGET))) {
perror("Failed to set environment variable");
exit(1);
}
char **new_argv = calloc(argc + 1, sizeof(char *));
new_argv[0] = xxx_path_to_firefox;
memcpy(new_argv, argv + 1, argc - 1);
execv(xxx_path_to_firefox, new_argv);
}you can then compile 1 per fuzz target we want, using |
|
@oliverchang to confirm that this will work in the CF's environment. |
|
@jonathanmetzman was discussing that we have a minor optimization on what we unpack, so in this case, we need to disable that somehow since we have to unarchive everything. |
|
Yes the stub approach should work in OSS-Fuzz's environment. There is also a |
|
So right now there seem two major blockers for this to work:
|
|
I have this working in principle, with the exception that |
|
I've been using |
|
Alright it's merged in, and hit the first problem. Now This worked in local testing. The rust installation is done in |
|
Args, still doesn't work. The problem is that And Since the images differ, I think guidance from Googlers is required. |
|
|
Works. The missing puzzle piece was passing the library. The question is how to teach it to oss-fuzz. Note that the internal fuzzing system is currently broken, which is also why coverage unexpectedly started building successfully. It'll stop building again. Perhaps best to disable it. Will this work in [[ $SANITIZER = "coverage" ]] && exit 0 |
Ahh, I see. I think we expect everything to be statically linked, so I don't handle shared libraries on OSS-Fuzz. Looks like I have to. In Chromium we handle it the following way: https://cs.chromium.org/chromium/src/tools/code_coverage/coverage.py?l=386
Yes, I think that would be fine. I'll probably delete |
|
@pdknsk - there is a startup leak happening 100% of the time, so no progess, if you want to disable leak checking, just add disabling in <fuzz_target_name>.options file. e.g. see projects/radare2/default.options https://oss-fuzz.com/v2/performance-report/libFuzzer_firefox_SdpParser/libfuzzer_asan_firefox/latest |
|
The problem with using Note that profile currently only builds in combination with @inferno-chromium I've submitted a PR that should take care of the outstanding issues. |
No, llvm-cov raises an error if any of the objects passed does not have coverage data section.
Yeah, that's not good, as it creates an additional overhead (while coverage instrumentation is already super heavy), but it still may work fine as an intermediate solution. |
What works to get profiled binaries and libraries is to run this on files in Only one library is really necessary here though, so if it can be passed manually, that works also. |
|
It's making progress, but there's still a problem. I'll change Also, exiting the coverage build still causes an error. Can be ignored though. I've also noticed that Then I'll sync the internal |
|
I assume |
|
Once #1726 gets resolved, you should be able to add |
I've been thinking, will it be able to resolve |
It depends on how I'll implement this :) But yeah I should either resolve |
|
It turns out that paths relative to the target work, so |
|
I've produced a full profile report now. Works well. Takes about 20 minutes, weighs in at more than I'm not sure about a few hundred of To |
|
@pdknsk thanks for noticing this. I probably should resolve symlinks when doing: |
|
It's failing with an error I don't understand. Still worked yesterday. The problem is in the build log. I don't know what the warning means. |
|
The problem appears to be this. There are three relevant files in the package.
|
|
It probably has changed since I added |
|
Unfortunately |
|
//cc @oliverchang for #1462 (comment) |
|
Looking from the name of the top frame I'm guessting it's from lack of shared memory. We don't provide /dev/shm in the minijail environment. |
|
I'm not familiar with the code, but from the comment of the class that appears to be the case. /**
* This class provides a simple, read-only key-value string store, with all
* data packed into a single segment of memory, which can be shared between
* processes.
*
* Look-ups are performed by binary search of a static table in the mapped
* memory region, and all returned strings are literals which reference the
* mapped data. No copies are performed on instantiation or look-up.
*
* Important: The mapped memory created by this class is persistent. Once an
* instance has been initialized, the memory that it allocates can never be
* freed before process shutdown. Do not use it for short-lived mappings.
*/Can anything be done about it? I assume not. |
|
Not in the short term unfortunately. We're planning some changes that will let us remove minijail completely, but that may not be for a while. |
|
Alright, I'll remove the target then. |
|
The target will live. I'll explain in an upcoming PR. |
|
Integration should be complete now, with address, undefined, and coverage working. I think no new targets will be added until |
I'd like to know what Googlers (and Mozillians) think of this.
There are currently two Firefox projects here:
qcmsandspidermonkey. Both build stand-alone and are also useful separate from Firefox. Firefox core does however have many more potential targets. I'll give a simple example: the FTP LIST parser. Please take a look.For such targets Firefox has a native fuzzing interface, which is integrated into its normal build system, and produces a binary that can be run with the normal libFuzzer flags. (ASAN-only currently.) Quite similar to how
spidermonkeyseems to be integrated here right now.Is this still within the scope of
oss-fuzz?The text was updated successfully, but these errors were encountered: