Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.17 at 16:48, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 14/02/17 08:55, Jan Beulich wrote:
>>>>> On 13.02.17 at 19:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 13/02/17 13:19, Jan Beulich wrote:
>>>> ---
>>>> TBD: Do we really want to re-init the TSS every time we are about to
>>>>      use it? This can happen quite often during boot, especially while
>>>>      grub is running.
>>> The only case we need worry about is if the guest manually writes to the
>>> area covered by the vm86 tss.  I think, looking at the logic, that we
>>> properly restore the old %tr when re-entering protected mode, so we
>>> aren't at risk of having the vm86 tss on the leaving-side of a hardware
>>> task switch.
>> Yes. But that's the whole point of the question: The guest could
>> equally well write to the TSS manually right after we've initialized
>> it. And it only harms itself by doing so, hence we could as well
>> init the TSS on a less frequently executed path.
> 
> Per this patch (I think) we initialise it each time the guest tries to
> clear CR0.PE
> 
> Unless the VM86_TSS location is below the 1MB boundary, the guest can't
> actually clobber it.

Is that the case? Don't we mimic big real mode (by using the
emulator for all insns)?

> As an alternative, if you don't reinitialise each time, when would you
> do so?

Well, ideally when the params get set, but see the reply just sent
to Tim's question in that direction. Alternatively we could track
whether either parameter changed, and gate the call to
hvm_prepare_vm86_tss() on that flag.

>>> We have lasted thus far without, but given the issues recently
>>> identified, the only safe conclusion to be drawn is that this
>>> functionality hasn't been used in anger.
>>>
>>> For sensible performance, we need to keep the IO bitmap clear to avoid
>>> taking the #GP emulation path.
>>>
>>> For correct behaviour, we need the entire software bitmap to be 0.
>> This one is just for reasonable performance too, afaict. If faulting,
>> just like with port accesses, we'd emulate the INT $nn.
> 
> Does that actually work?  Upon re-injection of the event, won't hardware
> follow the same bad path which caused the #GP fault to start with?

realmode_deliver_exception() does everything manually, so I don't
think there's any re-injection.

Jan


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