Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 30/01/17 10:43, Jan Beulich wrote:
>>>> On 27.01.17 at 20:43, <tim@xxxxxxx> wrote:
>>> Despite being owned by the guest, this TSS is actually managed by
>> Xen.
>>> It should be initialised to defaults each time Xen needs to use it
>> on
>>> behalf of the guest.
>> At 14:35 +0000 on 27 Jan (1485527708), Andrew Cooper wrote:
>>> On 27/01/17 14:01, Tim Deegan wrote:
>>>> Hi,
>>>>
>>>> At 13:46 +0000 on 27 Jan (1485524765), Andrew Cooper wrote:
>>>>> The actual behaviour can be determined by putting the TSS on a page
>>>>> boundary, making the previous frame non-readable via EPT, and seeing
>>>>> whether an EPT violation occurs.
>>>> Indeed.  Or likewise with normal pagetables. 
>>>>
>>>>>> Yes, I wonder about the I/O bitmap too.  We don't provide one, or even
>>>>>> enough space for a full one, but the current SDM is pretty clear that
>>>>>> the CPU will try to check it in virtual 8086 mode.
>>>>>>
>>>>>> It may be that all the ports actually used happen to fall in the 128
>>>>>> bytes of zeros that we provide.
>>>>> With an offset of 0, we actually provide 256 bytes of zeros in the
>>>>> bitmap within the TSS limit.
>>>> Sure, or at least 128 bytes of zeros and another 128 bytes of something.
>>> That is a good point.  Nothing prevents a guest exiting vm86 mode, and
>>> using a task switch to move to a new tss, which will cause Xen to write
>>> state back into the vm86_tss, making it no longer a zeroed block of memory.
>>>
>>> Despite being owned by the guest, this TSS is actually managed by Xen. 
>>> It should be initialised to defaults each time Xen needs to use it on
>>> behalf of the guest.
>> But it's already in an E820 reserved block - if the guest overwrites
>> it (with a task switch or otherwise) it will break real-mode support,
>> but this is no worse than nobbling any other part of the BIOS state.
>>
>> If we're making it non-zero, I can see an argument for having Xen init
>> the contents once (maybe when the HVM param is written?) so that it
>> matches what Xen expects of it.  But resetting it every time we use it
>> would be overkill.
> That wasn't the point Andrew was making, I think. A task switch
> initiated by the guest would make the hypervisor write into that
> TSS (as the outgoing one). Of course any sane guest would do an
> LTR first (or else it would risk memory near address zero to get
> clobbered on real hardware).

Thinking about it, this depends on whether we properly save and restore
the protected mode %tr around entering and exiting faked-up real mode.

If the saving and restoring is already done properly, then I think my
concern is unfounded.

~Andrew

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