[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: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 25 Jun 2024 18:12:57 +0200
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • 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 16:13:14 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.06.2024 17:20, Tamas K Lengyel wrote:
> 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.

The fuzzing stuff reuses files from the test harness, i.e.
tools/tests/x86_emulator/wrappers.c in this case. Much like cpuid.c
is coming from elsewhere, too.

Jan



 


Rackspace

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