Re: [Xen-devel] [PATCH v2 10/12] fuzz/x86emul: update fuzzer

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 31/01/17 15:51, Wei Liu wrote:
> On Tue, Jan 31, 2017 at 06:33:11AM -0700, Jan Beulich wrote:
>>> +static void setup_fpu_exception_handler(void)
>>> +{
>>> +    /* FIXME - just disable exceptions for now */
>>> +    unsigned long a;
>>> +
>>> +    asm volatile ( "fnclex");
>>> +    a=0x37f;                    /* FCW_DEFAULT in Xen */
>>> +    asm volatile ( "fldcw %0" :: "m" (a));
>>> +    a=0x1f80;                   /* MXCSR_DEFAULT in Xen */
>>> +    asm volatile ( "ldmxcsr %0" :: "m" (a) );
>>> +}
>> While I see that the FCW value has changed, the strange local
>> variable is still there. If you really want to keep it, please at least
>> add the missing spaces around the = signs. But I'd prefer
>>
>>     asm volatile ( "fldcw %0" :: "m" (0x37f /* FCW_DEFAULT in Xen */));
>>     asm volatile ( "ldmxcsr %0" :: "m" (0x1f80 /* MXCSR_DEFAULT in Xen */) );
>>
> This doesn't work.
>
> x86-insn-emulator-fuzzer.c:445:5: error: memory input 0 is not directly 
> addressable

Indeed.  Both fldcw and ldmxcsr can only take memory operands, so cannot
take immediate values in the inline asm.

>> And then - doesn't the ABI require these settings to be in effect
>> upon program startup anyway?
>>
> I'm not sure about this -- reading AMD64 ABI Draft 0.99.8 doesn't reveal
> much for me. But having the code arranged like this hasn't caused any
> SIGFPE so far.
>
> What do you suggest I do here?

The issue George hit was that AFL managed to emulate alternative loads,
which then caused SIGFPE's to start happening to the test harness.

IIRC, the easy fix was to reset this state before emulating each
instruction.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel