Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Ed White <edmund.h.white@intel.com>]

On 01/12/2015 02:00 AM, Jan Beulich wrote:
>>>> On 10.01.15 at 00:04, <edmund.h.white@intel.com> 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