| Message ID | 20240722112752.4981-1-tamas@tklengyel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v3,1/2] Add libfuzzer target to fuzz/x86_instruction_emulator | expand |
On 22.07.2024 13:27, Tamas K Lengyel wrote: > This target enables integration into oss-fuzz. Changing invalid input return > to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the > missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz > build. > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> > --- > v3: don't include libfuzzer-harness in target 'all' as it requires specific cc With this, how is it going to be built at all? Only by invoking the special target "manually" as it seems? Which sets this up for easy bit-rotting. I wonder what others think here ... Jan
On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 22.07.2024 13:27, Tamas K Lengyel wrote: > > This target enables integration into oss-fuzz. Changing invalid input return > > to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the > > missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz > > build. > > > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> > > --- > > v3: don't include libfuzzer-harness in target 'all' as it requires specific cc > > With this, how is it going to be built at all? Only by invoking the special > target "manually" as it seems? Which sets this up for easy bit-rotting. I > wonder what others think here ... Yes, by calling make with the specific target. It's not going to bitrot because oss-fuzz will pick up any regression on a daily basis to this target. I assume you would be interested in receiving the fuzzing reports so it would show as a build failure in case something broke it. Tamas
On 22.07.2024 15:51, Tamas K Lengyel wrote: > On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 22.07.2024 13:27, Tamas K Lengyel wrote: >>> This target enables integration into oss-fuzz. Changing invalid input return >>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the >>> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz >>> build. >>> >>> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> >>> --- >>> v3: don't include libfuzzer-harness in target 'all' as it requires specific cc >> >> With this, how is it going to be built at all? Only by invoking the special >> target "manually" as it seems? Which sets this up for easy bit-rotting. I >> wonder what others think here ... > > Yes, by calling make with the specific target. It's not going to > bitrot because oss-fuzz will pick up any regression on a daily basis > to this target. I assume you would be interested in receiving the > fuzzing reports so it would show as a build failure in case something > broke it. Please forgive my lack of knowledge here, but which part of whose infrastructure would pick up stuff in a daily basis, and what fuzzing reports (I've never seen any, daily or not) are you talking about? For now it feels to me as if you're talking of what's possible down the road, not what's going to happen from the moment this patch was committed in a 2nd try. If so, the gap between both points in time may be significant, and hence my bit-rotting concern would still apply. Jan
On Mon, Jul 22, 2024 at 9:57 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 22.07.2024 15:51, Tamas K Lengyel wrote: > > On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 22.07.2024 13:27, Tamas K Lengyel wrote: > >>> This target enables integration into oss-fuzz. Changing invalid input return > >>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the > >>> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz > >>> build. > >>> > >>> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> > >>> --- > >>> v3: don't include libfuzzer-harness in target 'all' as it requires specific cc > >> > >> With this, how is it going to be built at all? Only by invoking the special > >> target "manually" as it seems? Which sets this up for easy bit-rotting. I > >> wonder what others think here ... > > > > Yes, by calling make with the specific target. It's not going to > > bitrot because oss-fuzz will pick up any regression on a daily basis > > to this target. I assume you would be interested in receiving the > > fuzzing reports so it would show as a build failure in case something > > broke it. > > Please forgive my lack of knowledge here, but which part of whose > infrastructure would pick up stuff in a daily basis, and what fuzzing > reports (I've never seen any, daily or not) are you talking about? > For now it feels to me as if you're talking of what's possible down > the road, not what's going to happen from the moment this patch was > committed in a 2nd try. If so, the gap between both points in time > may be significant, and hence my bit-rotting concern would still > apply. Once these two patches are merged to Xen I'll send my PR to oss-fuzz to have it pull Xen daily and build this fuzzer and run it on their infrastructure. It usually takes them less than 24 hours to respond to PRs, I have added multiple projects there already so the "lag" you worry about it's not something to worry about. Having these two patches upstream in Xen is not required by the way, I could just send these to be upstream to oss-fuzz and have them apply them after it pulling the xen git repo but it gives more flexibility to you guys to add additional fuzzers in the future more easily if these are in your repository because you don't even have to touch oss-fuzz afterwards. If you need to learn more about what oss-fuzz is and how it operates they have a quite nice documentation. Tamas
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile b/tools/fuzz/x86_instruction_emulator/Makefile index 1e4c6b37f5..459743f4d9 100644 --- a/tools/fuzz/x86_instruction_emulator/Makefile +++ b/tools/fuzz/x86_instruction_emulator/Makefile @@ -58,6 +58,9 @@ afl-harness: afl-harness.o $(OBJS) cpuid.o wrappers.o afl-harness-cov: afl-harness-cov.o $(patsubst %.o,%-cov.o,$(OBJS)) cpuid.o wrappers.o $(CC) $(CFLAGS) $(GCOV_FLAGS) $(addprefix -Wl$(comma)--wrap=,$(WRAPPED)) $^ -o $@ +libfuzzer-harness: $(OBJS) cpuid.o wrappers.o + $(CC) $(CFLAGS) $(LIB_FUZZING_ENGINE) -fsanitize=fuzzer $(addprefix -Wl$(comma)--wrap=,$(WRAPPED)) $^ -o $@ + # Common targets .PHONY: all all: x86-insn-fuzz-all @@ -67,7 +70,8 @@ distclean: clean .PHONY: clean clean: - rm -f *.a *.o $(DEPS_RM) afl-harness afl-harness-cov *.gcda *.gcno *.gcov + rm -f *.a *.o $(DEPS_RM) *.gcda *.gcno *.gcov + rm -f afl-harness afl-harness-cov libfuzzer-harness rm -rf x86_emulate x86-emulate.c x86-emulate.h wrappers.c cpuid.c .PHONY: install diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c index eeeb6931f4..2ba9ca9e0b 100644 --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c @@ -906,14 +906,12 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size) if ( size <= DATA_OFFSET ) { - printf("Input too small\n"); - return 1; + return -1; } if ( size > FUZZ_CORPUS_SIZE ) { - printf("Input too large\n"); - return 1; + return -1; } memcpy(&input, data_p, size); diff --git a/tools/tests/x86_emulator/wrappers.c b/tools/tests/x86_emulator/wrappers.c index 3829a6f416..8f3bd1656f 100644 --- a/tools/tests/x86_emulator/wrappers.c +++ b/tools/tests/x86_emulator/wrappers.c @@ -91,6 +91,17 @@ int __wrap_snprintf(char *buf, size_t n, const char *fmt, ...) return rc; } +int __wrap_vsnprintf(char *buf, size_t n, const char *fmt, va_list varg) +{ + int rc; + + emul_save_fpu_state(); + rc = __real_vsnprintf(buf, n, fmt, varg); + emul_restore_fpu_state(); + + return rc; +} + char *__wrap_strstr(const char *s1, const char *s2) { char *s;
This target enables integration into oss-fuzz. Changing invalid input return to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz build. Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> --- v3: don't include libfuzzer-harness in target 'all' as it requires specific cc --- tools/fuzz/x86_instruction_emulator/Makefile | 6 +++++- tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 6 ++---- tools/tests/x86_emulator/wrappers.c | 11 +++++++++++ 3 files changed, 18 insertions(+), 5 deletions(-)