Re: [Xen-devel] [PATCH 2/2] x86/HVM: re-order operations in hvm_ud_intercept()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/06/16 15:13, Jan Beulich wrote:
>>>> On 09.06.16 at 16:06, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 09/06/16 13:31, Jan Beulich wrote:
>>>>>> On 09.06.16 at 13:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 08/06/16 14:43, Jan Beulich wrote:
>>>>> Don't fetch CS explicitly, leverage the fact that hvm_emulate_prepare()
>>>>> already does (and that hvm_virtual_to_linear_addr() doesn't alter it).
>>>>>
>>>>> At once increase the length passed to hvm_virtual_to_linear_addr() by
>>>>> one: There definitely needs to be at least one more opcode byte, and we
>>>>> can avoid missing a wraparound case this way.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> I looked into this when you suggested it, but it latches the wrong eip
>>>> in the emulation state, and you will end up re-emulating the ud2a
>>>> instruction, rather than the following instruction.
>>> Where is there any latching of eip? All hvm_emulate_prepare() does
>>> is storing the regs pointer.
>> Oh - so it does.  I clearly looked over it too quickly.
>>
>> What wraparound issue are you referring to?  Adding 1 will cause
>> incorrect behaviour when the emulation prefix ends at the segment limit.
> I don't think so: The prefix together with the actual instruction
> encoding should be viewed as a single instruction, and it crossing
> the segment limit should #GP. It wrapping at the prefix/encoding
> boundary is the case that I'm specifically referring to (this case
> should also #GP, but wouldn't without this adjustment).

But the force emulation prefix specifically doesn't behave like other
prefixes.

It doesn't count towards the 15 byte instruction limit, and if the
emulated instruction does fault, we want the fault pointing at the
emulated instruction, not the force prefix.  We should avoid making any
link.

~Andrew

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