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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.10.17 at 12:50, <george.dunlap@xxxxxxxxxx> wrote:
> 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.

Ah, indeed.

Jan


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