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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.08.14 at 18:08, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
>> On Wed, Aug 06, 2014 at 03:04:31AM +0000, Zhang, Yang Z wrote:
>> > Malicious guest is just an example. We can assume a normal guest never
>> does it.
>> 
>> What!? No you can't. That is thundering towards an XSA! The normal
>> guest can become compromised.
> 
> 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
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).

Jan


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