[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m
On 01/12/2015 02:00 AM, Jan Beulich wrote: >>>> On 10.01.15 at 00:04, <edmund.h.white@xxxxxxxxx> wrote: >> On 01/09/2015 02:41 PM, Andrew Cooper wrote: >>> Having some non-OS part of the guest swap the EPT tables and >>> accidentally turn a DMA buffer read-only is not going to end well. >>> >> >> The agent can certainly do bad things, and at some level you have to assume >> it >> is sensible enough not to. However, I'm not sure this is fundamentally more >> dangerous than what a privileged domain can do today using the MEMOP... >> operations, and people are already using those for very similar purposes. > > I don't follow - how is what privileged domain can do related to the > proposed changes here (which are - via VMFUNC - at least partially > guest controllable, and that's also the case Andrew mentioned in his > reply)? I'm having a hard time understanding how a P2M stripped of > anything that's not plain RAM can be very useful to a guest. IOW > without such fundamental aspects clarified I don't see a point in > looking at the individual patches (which btw, according to your > wording elsewhere, should have been marked RFC). > > Jan > In this patch series, none of the new hypercalls are protected by xsm policies. Earlier in the process of working on this code, I added such a check to all the hypercalls, but then removed them all because it dawned on me that I didn't actually understand what I was doing and my code only worked because I only ever built the dummy permit everything policy. Should some version of this patch series be accepted, my hope is that someone who does understand xsm policies would put the appropriate checks in place, and at that point I maintain that these extra capabilities would not be fundamentally more dangerous than existing mechanisms available to privileged domains, because policy can prevent the guest using vmfunc. That's obviously not true today. The alternate p2m's only contain entries for ram pages with valid mfn's. All other page types are still handled in the nested page fault handler for the host p2m. Those pages (at least the ones I've encountered) don't require the hardware to have a valid EPTE for the page. Ed _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |