On 30.04.2025 04:17, Volodymyr Babchuk wrote: > Julien Grall <jul...@xen.org> 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). Jan
