Re: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page write protection

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.08.14 at 18:28, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, August 06, 2014 11:45 PM
>> >>> On 06.08.14 at 18:08, <kevin.tian@xxxxxxxxx> wrote:
>> > It would be a severe security hole to write-protect only the CPU path while
>> > leaving DMA writes valid. When we say a page is write-protected, it must be
>> > consistently enforced in both CPU/DMA paths. Now there is no other way to
>> > achieve it lacking of VT-d page fault, except treating it fully as a 
>> > emulated
>> > MMIO range (means removing mapping in both EPT/VT-d page table), or
>> > excluding VT-d like this patch originally does.
>> 
>> A fully emulated range means more than just removing the mapping
>> though: No passed through device must access the memory range,
>> since you can't emulate such accesses. While this is fine for existing
>> uses (LAPIC, HPET, ...), I don't think it is for things like a frame
>> buffer. If otoh talk is exclusively about GPU page tables, then this
> 
> I don't understand here. why would a pass-through device wants to access
> frame buffer (I think you meant 'virtual' frame buffer)? Note XenGT itself
> doesn't use VT-d, and we didn't see such usage of having another device
> DMA to GPU resource. Then it's just same as any existing emulated MMIO
> ranges e.g. on a virtual NIC, where no pass-through device would access 
> them.

This is the same as the discussion about VT-d code not supporting
large pages right now: An OS _might_ do clever things (merely
dumping the frame buffer verbatim to disk or network would be one
of the more trivial examples). Current OSes (or more precisely
their drivers) may not do this, but I can only repeat my fundamental
position here: We should not make assumptions about HVM guest
behavior except in cases where we want to optimize certain things.

>> ought to be fine, but would - to me - not fit with other aspects
>> discussed in the context of these patches (like the supposedly large
>> number of pages needing to be tracked for a guest).
> 
> So what's your suggestion here?

I can't answer that without you clarifying whether talk earlier on
was about the frame buffer or page tables.

Jan


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