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

Re: [RFC PATCH v2] xen: add libafl-qemu fuzzer support


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Wed, 30 Apr 2025 12:19:11 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6u0LZnp5OfwJNKBFY1it0+I2TAuIPUj2L9Ln1iIjojk=; b=aHP0P1kYFg1b/2IJ4WeAfH102zOF0d8xG3Om1GCipk09w/aSt7JlNya1jHGJJZZZiwtyb5mcf9tkT9umMj8GIHm4L5rAoG6LnBIGpQjVUQmwkWve4DCBj8CMK2fB2W1eu6NbztM/teX/BNuzvS9JVbSLhgyGYL9uIW/TSlJdbIMqezbL1RfskL6sfXnuwBsslMCRCTUGWuezF6rP2iwrJzPVlI8g7Bnl743mS3KhpubP5GW1Nyvfzu2LG6xPNbbUnDoa90Ew0+pvYQY7JWsawc2Gd7kqujAfsql9lfVV/smURNQnqmf9NBn4If6C6vLy6ftMx4s11HJBo9ytl7qaPg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nQaNIrN0Bj30PMIjN7xlCIycPFPieOMhnxfz2YtWlZjiGbs4RtoDVGoGhcLNHLJkej5K0xfxawxEdA/+p5pXnP+2eQPMOd5BbIez6FY8Lz4MCrVTvar6HqVLeWAVWb5Wz+erluGCJycMBIxGHob3lAqkAaMuAjcIit+E5QqI5NtTTyMl8/Y+G2o7bkKM3h57B7Bekj+oknrrJydhfOFHiP2ZVP3sVe2MLR5D2xf7Jsk3z06UnX/j65CNioZIrV+BVeGBcPAsNPPad95cJIhEadggIC/oOKhiZBgTqSNdrENev5ssinYalmaemUqnwB6oElnfFZrEx17+YCIbOrdT1w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Wed, 30 Apr 2025 12:19:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHblUI7lWJ91U/YVk+TK2sT0KKY9g==
  • Thread-topic: [RFC PATCH v2] xen: add libafl-qemu fuzzer support

Jan Beulich <jbeulich@xxxxxxxx> writes:

> On 30.04.2025 04:17, Volodymyr Babchuk wrote:
>> Julien Grall <julien@xxxxxxx> writes:
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/include/asm/libafl_qemu_defs.h
>>>> @@ -0,0 +1,37 @@
>>>
>>> Missing license. Also, is this file taken from somewhere?
>>>
>> 
>> I add MIT license, as libafl is dual licensed under Apache-2 and
>> MIT. This file is based on libafl_qemu [1]
>> 
>>>> +#ifndef LIBAFL_QEMU_DEFS
>>>> +#define LIBAFL_QEMU_DEFS
>>>> +
>>>> +#define LIBAFL_STRINGIFY(s) #s
>>>> +#define XSTRINGIFY(s) LIBAFL_STRINGIFY(s)
>>>> +
>>>> +#if __STDC_VERSION__ >= 201112L
>>>> +  #define STATIC_CHECKS                                   \
>>>> +    _Static_assert(sizeof(void *) <= sizeof(libafl_word), \
>>>> +                   "pointer type should not be larger and libafl_word");
>>>> +#else
>>>> +  #define STATIC_CHECKS
>>>> +#endif
>>>
>>> No-one seems to use STATIC_CHECKS? Is this intended?
>> 
>> I used this file as is... But I'll rework this part.
>> 
>>>> +
>>>> +#define LIBAFL_SYNC_EXIT_OPCODE 0x66f23a0f
>>>> +#define LIBAFL_BACKDOOR_OPCODE 0x44f23a0f
>>>
>>> Are the opcode valid for arm32? If not, they should be protected with
>>> #ifdef CONFIG_ARM_64.
>>>
>> 
>> It is valid even for x86_64. They use the same opcode for x86_64, arm,
>> aarch64 and riscv.
>
> Wow. On x86-64 they rely on the (prefix-less) opcode 0f3af2 to not gain
> any meaning. Somewhat similar on RISC-V, somewhere in MISC_MEM opcode
> space. Pretty fragile. Not to speak of what the effect of using such an
> opcode is on disassembly of surrounding code (at least for x86).

Yeah, they made some questionable choices, and opcode selection is one
of them. Also, the whole libafl-qemu code quality is not to the highest
standard, but there are no better alternatives.

They just hacked into TCG translator code and are looking for the their
special opcodes byte-per-byte:

[1] 
https://github.com/AFLplusplus/qemu-libafl-bridge/blob/main/accel/tcg/translator.c#L184


-- 
WBR, Volodymyr


 


Rackspace

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