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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/01/17 13:20, Tim Deegan wrote:
> Hi,
>
> At 12:51 +0000 on 27 Jan (1485521470), Andrew Cooper wrote:
>> On 27/01/17 11:14, Tim Deegan wrote:
>>> But looking at it now, I'm not convinced of exactly how.  The magic
>>> bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
>>> base address itself lives at offset 100.  A zero'd TSS should mean an
>>> I/O map at 0, and an interrupt redirection bitmap at -32, which would
>>> plausibly work if the TSS were 256 bytes (matching the limit set in
>>> Xen).  Perhaps it's only working because the 128 bytes following the
>>> TSS in hvmloader happen to be zeros too?
>> With an IO_base_map of 0, the software interrupt bitmap will end up
>> being ahead of the TSS, not after it.
> I should have thought that the segmented address calculation would
> wrap and leave us at TSS + 224.

As far as I am aware, this is the only case of a system descriptor
access which could end up negative (relative to base).  All IDT/GDT/LDT
accesses are sensibly bounded by the validity of their trigger conditions.

I'd expect microcode to calculate TSS.base + I/O base - 32 +
bit_of(vector) on the expectation that an OS actually wanting this to
work would have set it up properly.

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.  (I haven't yet got far enough in my
nested virt work for this to be an easy thing to configure, but it is
possible by manually clobbering unrestricted mode on a newer processor
and using HAP.)

>
>>> I also don't remember why the TSS is 128 rather than 104 bytes.  The
>>> SDM claims that the TSS must be larger than 104 bytes "when accessing
>>> the I/O permission bit map or interrupt redirection bit map."
>>> (7.2.2. "TSS Descriptor") but I suspect that just means that the
>>> generated address of the bitmap must lie inside the limit.
>> The documented way of expressing "no IO bitmap" is to set the map base
>> to a value which exceeds the TSS limit.  All this means (I think) is
>> that you must make a larger than default TSS if you want to use a IO or
>> software interrupt bitmap.
> 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.

> Or possibly (both for this and the interrupt bitmap) we are causing
> #GP and somehow ending up exiting-and-emulating.  But I don't see
> quite what the path is for that.

We set IOPL to 3 as well as when entering vm86 to fake up real mode. 
This bypasses all I/O bitmap checks (a properly common to ring 3
protected tasks as well - See specifically 20.2.7 "Sensitive
Instructions"), which means the IN/OUT instructions end up directly at
the relevant vmexit case.

~Andrew

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