[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page write protection
> From: Tian, Kevin > Sent: Friday, August 08, 2014 9:02 AM > > > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > > Sent: Thursday, August 07, 2014 11:33 PM > > > > >>> 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. > > with a complete HW support yes we should make assumption for guest should -> shouldn't > behavior (e.g. with VT-x we can support any type of OS), but when HW > support in VT-d is not fully ready, then making some assumption makes > sense especially when no real usage is observed in this case. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |