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

Re: [Xen-devel] [PATCH v2 12/13] fuzz/x86_emulate: Set and fuzz more CPU state



On 10/06/2017 10:57 AM, Jan Beulich wrote:
>>>> On 05.10.17 at 19:08, <george.dunlap@xxxxxxxxxx> wrote:
>> On 10/04/2017 09:28 AM, Jan Beulich wrote:
>>>>>> On 25.09.17 at 16:26, <george.dunlap@xxxxxxxxxx> wrote:
>>>> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>>>>  };
>>>>  #undef SET
>>>>  
>>>> +static void _set_fpu_state(char *fxsave, bool store)
>>>> +{
>>>> +    if ( cpu_has_fxsr )
>>>> +    {
>>>> +        static union __attribute__((__aligned__(16))) {
>>>> +            char x[464];
>>>
>>> The final part of the save area isn't being written, yes, but is it
>>> really worth saving the few bytes of stack space here, rather than
>>> having the expected 512 as array dimension?
>>
>> So I didn't actually look into this very much; I mainly just hacked at
>> it until it seemed to work.  I copied-and-pasted emul_test_init() from
>> x86_emulate.c (which is where the 464 came from), then copied some
>> scraps of asm from stackoverflow.
> 
> One thing that came to mind in this context: It would perhaps be
> useful to not waste input bytes on the unused portions of the
> save area. Along those lines it may also be worth considering not
> to waste input on the high halves of 64-bit registers as well as
> the high 8 GPRs when emulating 32- or 16-bit mode.

Well with the 'compact' mode we're not wasting anything -- AFL may 'try'
to write to those areas (by setting the <offset> word to those areas),
but it will find that nothing happens and not generate any test cases there.

Even for the high ends of the GPRs, if garbage in those *did* cause a
crash in 32- or 16-bit mode, we'd definitely want to know, wouldn't we?
We'd want to fix it anyway, and we'd need to make sure there wasn't a
way for a guest to trigger that situation with the emulator.

 -George

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

 


Rackspace

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