[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] Add libfuzzer target to fuzz/x86_instruction_emulator


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Date: Tue, 25 Jun 2024 11:20:59 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=tklengyel.com; spf=pass smtp.mailfrom=tamas@xxxxxxxxxxxxx; dmarc=pass header.from=<tamas@xxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1719328899; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=rOO9Vy49/Zqy206+4uypFYbo55wn+kwzAS1UCif3ofs=; b=VW2Jd1cQiojy5YttjIcS9JmJWAjSDKmFCY7z8kATEz11K6zFkzO+S5YAb1u8akZckCk3Sx770wq4OMJfZu1d5mjSBJUzrrXm7bpUVePMxmRvu06N7Rys0bZJcr6KWa9VJH13FpzQJYOtbpesO1z8SIXhjh1sInXHMMdmCKAKiSE=
  • Arc-seal: i=1; a=rsa-sha256; t=1719328899; cv=none; d=zohomail.com; s=zohoarc; b=E9ZznQtQ8sMvbPQ4mBsdkDcfQMRZURukXWvvYVxF6MZQSMajoDutjLKGXOfn1xTFiEMpem43S7+dlSzampvkyXMzoT7Qd8sR7nGdU0HrIhi/ZIZaJYiHvGe3L/V2xjgpDYQFJvkY94PMHAKzCu+c982GGnMjf+XHp72B029f9Yk=
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 25 Jun 2024 15:21:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Jun 25, 2024 at 10:56 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 25.06.2024 15:40, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 25.06.2024 14:40, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>>>
> >>>> On 25.06.2024 13:12, Tamas K Lengyel wrote:
> >>>>> On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>>>>>
> >>>>>> On 24.06.2024 23:23, Tamas K Lengyel wrote:
> >>>>>>> On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich <jbeulich@xxxxxxxx> 
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>>>>>>>> @@ -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
> >>>>>>>>> +     $(CC) $(CFLAGS) $(LIB_FUZZING_ENGINE) -fsanitize=fuzzer $^ -o 
> >>>>>>>>> $@
> >>>>>>>>
> >>>>>>>> What is LIB_FUZZING_ENGINE? I don't think we have any use of that in 
> >>>>>>>> the
> >>>>>>>> tree anywhere.
> >>>>>>>
> >>>>>>> It's used by oss-fuzz, otherwise it's not doing anything.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I'm further surprised you get away here without wrappers.o.
> >>>>>>>
> >>>>>>> Wrappers.o was actually breaking the build for oss-fuzz at the linking
> >>>>>>> stage. It works just fine without it.
> >>>>>>
> >>>>>> I'm worried here, to be honest. The wrappers serve a pretty important
> >>>>>> role, and I'm having a hard time seeing why they shouldn't be needed
> >>>>>> here when they're needed both for the test and afl harnesses. Could
> >>>>>> you add some more detail on the build issues you encountered?
> >>>>>
> >>>>> With wrappers.o included doing the build in the oss-fuzz docker
> >>>>> (ubuntu 20.04 base) fails with:
> >>>>>
> >>>>> ...
> >>>>> clang -O1 -fno-omit-frame-pointer -gline-tables-only
> >>>>> -Wno-error=enum-constexpr-conversion
> >>>>> -Wno-error=incompatible-function-pointer-types
> >>>>> -Wno-error=int-conversion -Wno-error=deprecated-declarations
> >>>>> -Wno-error=implicit-function-declaration -Wno-error=implicit-int
> >>>>> -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address
> >>>>> -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -m64
> >>>>> -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> >>>>> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -g3 -Werror
> >>>>> -Og -fno-omit-frame-pointer
> >>>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP
> >>>>> -MF .libfuzzer-harness.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> >>>>> -I/src/xen/tools/fuzz/x86_instruction_emulator/../../../tools/include
> >>>>> -D__XEN_TOOLS__ -iquote . -fsanitize=fuzzer -fsanitize=fuzzer
> >>>>> -Wl,--wrap=fwrite -Wl,--wrap=memcmp -Wl,--wrap=memcpy
> >>>>> -Wl,--wrap=memset -Wl,--wrap=printf -Wl,--wrap=putchar -Wl,--wrap=puts
> >>>>> -Wl,--wrap=snprintf -Wl,--wrap=strstr -Wl,--wrap=vprintf
> >>>>> -Wl,--wrap=vsnprintf fuzz-emul.o x86-emulate.o x86_emulate/0f01.o
> >>>>> x86_emulate/0fae.o x86_emulate/0fc7.o x86_emulate/decode.o
> >>>>> x86_emulate/fpu.o cpuid.o wrappers.o -o libfuzzer-harness
> >>>>> /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 
> >>>>> 0x25
> >>>>> /usr/local/lib/clang/18/lib/x86_64-unknown-linux-gnu/libclang_rt.fuzzer.a(fuzzer.o):
> >>>>> in function `std::__Fuzzer::__libcpp_snprintf_l(char*, unsigned long,
> >>>>> __locale_struct*, char const*, ...)':
> >>>>> cxa_noexception.cpp:(.text._ZNSt8__Fuzzer19__libcpp_snprintf_lEPcmP15__locale_structPKcz[_ZNSt8__Fuzzer19__libcpp_snprintf_lEPcmP15__locale_structPKcz]+0x9a):
> >>>>> undefined reference to `__wrap_vsnprintf'
> >>>>> clang: error: linker command failed with exit code 1 (use -v to see 
> >>>>> invocation)
> >>>>> make: *** [Makefile:62: libfuzzer-harness] Error 1
> >>>>> rm x86-emulate.c wrappers.c cpuid.c
> >>>>> make: Leaving directory '/src/xen/tools/fuzz/x86_instruction_emulator'
> >>>>> ERROR:__main__:Building fuzzers failed.
> >>>>
> >>>> Hmm, yes, means we'll need an actual vsnprintf() wrapper, not just a
> >>>> declaration thereof.
> >>>
> >>> I don't really get what this wrapper accomplishes
> >>
> >> They guard against clobbering of in-register state (SIMD registers in
> >> particular, but going forward maybe also eGRP-s as introduced by APX)
> >> by library functions called between emulation of individual insns (or,
> >> especially possible for fuzzing instrumented code, I think) even from
> >> in the middle of emulating an insn. (Something as simple as the
> >> compiler inserting a call to memcpy() or memset() somewhere in the
> >> translation of the emulator source code could also clobber state.)
> >>
> >>> and as I said, fuzzing works with oss-fuzz just fine without it.
> >>
> >> I'm inclined to take this as "it appears to work just fine". Fuzzed
> >> input register state may be lost by doing a library call somewhere,
> >> rendering the fuzzing results less useful. This would pretty
> >> certainly stop being tolerable the moment you compared results of
> >> native execution of a sequence of instructions with the emulated
> >> counterpart.
> >
> > Yea, that may be. Any suggested way to fix the linking issue though?
>
> As said before, we need to gain a real wrapper for vsnprintf(). Right
> now we only have a declaration thereof, for use by the wrapper for
> snprintf().

Where is this wrapper for snprintf? I can't find anything in
fuzz/x86_instruction_emulator. If I can see an example for one that's
implemented already I may be able to decipher what's needed here. At
the moment I don't really know what "a real wrapper" would look like.

Tamas



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.