Re: [Xen-devel] [PATCH 2/2] x86emul: adjust MOVSXD source operand handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/09/2019 10:31, Jan Beulich wrote:
> On 18.09.2019 21:22, Andrew Cooper wrote:
>> On 18/09/2019 07:34, Jan Beulich wrote:
>>> On 17.09.2019 19:17, Andrew Cooper wrote:
>>>> On 16/09/2019 10:48, Jan Beulich wrote:
>>>>> XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
>>>>> that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
>>>>> memory (or register) when used without REX.W and with operand size
>>>>> override. Since the upper 16 bits of the value read won't be used
>>>>> anyway in this case, make the emulation uniformly follow this more
>>>>> compatible behavior when not emulating an AMD-like CPU, at the risk
>>>>> of missing an exception when emulating on/for older hardware (the
>>>>> boundary at SandyBridge noted in said commit looks questionable - I've
>>>>> observed the "new" behavior also on Westmere).
>>>> AMD documents this instruction has always using an 8 or 16bit source
>>>> operand.
>>> Have you mixed up MOVSX with MOVSXD? Both have separate pages in
>>> AMD's doc, but a common page in Intel's.
>> I had confused the two, yes.
>>
>> I constructed an experiment using 66 6e 08, i.e.
>>
>> movslq (%rax),%cx
>>
>> according to objdump, and iterating backwards over the boundary to the
>> unmapped page at 0.
>>
>> On a Rome system:
>>
>> (d24) Ptr: 0000000000001000
>> (d24)  => c2c2
>> (d24) Ptr: 0000000000000fff
>> (d24) ******************************
>> (d24) PANIC: Unhandled exception at 0008:00000000001047a5
>> (d24) Vec 14 #PF[-d-sr-] %cr2 0000000000000fff
>> (d24) ******************************
>>
>> Which also confirms the description which states that in the case of a
>> 16 bit operand, no sign extension occurs.
>>
>> I then tried the same test on an Intel Haswell system:
>>
>> (d91) Ptr: 0000000000001000
>> (d91)  => c2c2
>> (d91) Ptr: 0000000000000fff
>> (d91) ******************************
>> (d91) PANIC: Unhandled exception at 0008:00000000001047a5
>> (d91) Vec 14 #PF[-d-sr-] %cr2 0000000000000fff
>> (d91) ******************************
> But judging from the "Ptr: 0000000000000fff" in the log I take
> it you tried to access a byte rather than a word (which would
> need an address of 0000000000000ffe to distinguish whether it's
> a 2- or 4-byte read that the CPU issues).

No - it was a word access in all cases.  The bug was walking backwards
into an unmapped page, rather than forward.

When walking forward from 0x1ffc to 0x2000, I do observe that AMD does
4-byte accesses while Intel does 2.

> Trust me, I did try
> this out, which is also why I noticed that Mark's claim of
> the behavior having changed with SandyBridge is likely wrong.
> He has meanwhile confirmed that Merom also already behaved this
> way.

Sadly, we also have a second bug here, and it is rather more complicated
to reason about.

The shadow livelock bug with implicit supervisor accesses to user
mappings happens when the pipeline generates #PF, and the emulator
believes that the instruction completes correctly.  The SMAP case
specifically occurs because information is discarded on VMExit which
prevents Xen's pagewalk from behaving identically to the pipeline. 
However, any case where hardware and the emulator disagree is a recipe
for livelock.

In this example, hardware can the emulator can disagree by using a
different access width.

I've been experimenting with my Rome system, and an emulator hardcoded
to use 2-byte accesses.  After some investigation, the livelock only
occurs for access-rights faults.  Translation faults get identified as
not a shadow fault, and bounced back to the guest.

Shadow guests can use PKRU, so can generate an access fault by marking
the page at 0x2000 as no-access, so I think that in principle, this
change will result in a new latent livelock case, but I can't actually
confirm it.

For now, I don't think this will interact problematically with
mem-access reduced p2m types, because they are ignored by the emulator.

However, I think we need to tread very carefully here.

~Andrew

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