Re: [Xen-devel] [PATCH 2/3] tests/x86emul: Save and restore FPU state in the emulator callbacks

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/03/18 11:41, Jan Beulich wrote:
>>>> On 06.03.18 at 21:24, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Currently with then native toolchain on Debian Jessie ./test_x86_emulator
>> yeilds:
>>
>>   Testing AVX2 256bit single native execution...okay
>>   Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
>>
>> The bug is that libc's memcpy() in read() uses %xmm8 (specifically, in
>> __memcpy_sse2_unaligned()), which corrupts %ymm8 behind the back of the AVX2
>> test code.
>>
>> Switch all hooks to use "goto out" style returns, and use
>> emul_{save,restore}_fpu_state().
> "Switch hooks to  use "goto out" style returns as necessary, and ..."?
> You don't even touch all of them, and even one of those that you
> touch doesn't obtain any "goto".
>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> As an immediate workaround
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> (also for patch 4)
>
> But of course this doesn't fully deal with the problem: Structure
> assignments may still cause library functions to be invoked. Plus
> there are explicit uses of memcpy() [which look safe] and
> memset() [most or even all of which don't] in the core emulator.
> I was therefore considering to instead provide hidden visibility
> wrappers inside the binary, which would save/forward/restore.
> That would also deal with someone wanting to add some printf()
> in the middle of e.g. x86_emulate() for debugging purposes.
>
> Obviously sooner or later we'll need the same for the fuzzer hooks;
> that alternative approach would perhaps result in less code churn
> there as well (the source to provide the wrappers could likely be
> shared).

I'm afraid that I don't understand what you mean here.  Are you
proposing that we wrap all libc functions, and ifso, how?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel