Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 07/09/2018 12:18 PM, Razvan Cojocaru wrote:
> On 07/09/2018 02:04 PM, George Dunlap wrote:
>> On 07/06/2018 05:52 PM, Tamas K Lengyel wrote:
>>> On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru
>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>
>>>> On 07/05/2018 07:45 PM, Tamas K Lengyel wrote:
>>>>> On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru
>>>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>> However, our particular application is only interested in setting (and
>>>>>> querying) page restrictions from userspace (from the dom0 agent). It
>>>>>> will also need to be able to set the convertible bit of guest pages from
>>>>>> the dom0 agent as well (patches pending). So we're also fine with a
>>>>>> "DOMCTL if nobody wants it as a HVMOP" policy, if polluting the DOMCTLs
>>>>>> (possibly temporarily) is an option.
>>>>>>
>>>>>> We could also (at least between Tamas and us) come up with current /
>>>>>> likely use-cases and downgrade all altp2m HVMOPs that could be DOMCTLs
>>>>>> in all the scenarios to DOMCTLs.
>>>>>
>>>>> Aye. There is really just one HVMOP that the guest absolutely needs
>>>>> access to so that it can use #VE, and that's
>>>>> HVMOP_altp2m_vcpu_enable_notify. AFAIU everything else could be just a
>>>>> DOMCTL.
>>>>
>>>> We need even less than that - we want to modify
>>>> HVMOP_altp2m_vcpu_enable_notify to be able to call it from dom0 as well,
>>>> and we don't call it from the in-guest agent ever. Because we agree that
>>>> the smallest attack surface is a requirement, all we ever call that's
>>>> #VE / altp2m related is actually from the privileged domain doing
>>>> introspection. The in-guest driver only needs to do VMFUNC and be able
>>>> to communicate with the dom0 introspection agent.
>>
>> For some reason my impression was that Intel was hoping to be able to
>> enable a guest-only usage as well -- that basically a guest which had
>> been booted (say) with measured boot, and then wrote its own enclave
>> using #VE and altp2ms, should be able to allow an in-guest agent to be
>> reasonably secure and also keep tabs on the operating system.  Was this
>> not your impression?
> 
> The wording on their initial design document does say:
> 
> "- Hypercalls for altp2m
> 
> Altp2m mode introduces a new set of hypercalls for altp2m management
> from software agents operating in Xen HVM guests.
> 
> The hypercalls are as follows:
> 
> Enable or Disable altp2m mode for domain
> Create a new alternate p2m
> Edit permissions for a specific GPA within an alternate p2m
> Destroy an existing alternate p2m"
> 
> But I've always suspected that it might have been just what they have
> thought would offer the most possibilities.
> 
> The problem with in-guest agents doing all these things is that it kind
> of kills the whole "the introspection cannot be stopped or manipulated
> at all from within the guest" assumption that gives hypervisor-level
> introspection its edge - because then it's possible for in-guest code to
> bypass dom0-based introspection by simply switching to a non-restricted
> EPTP index, or editing the restricted pages permissions. And we're back
> to in-guest protection.

I don't think you've quite gotten the design in mind here.  The idea is
that *all* of the "introspection" happens inside the guest.  The guest
agent is given all the tools it needs to protect itself even from the
guest operating system.  Just having a chat with Andy, apparently Intel
actually had just such an agent once upon a time, and used this
interface on Xen for real.

I think there are advantages to each model.  Obviously having something
run in the guest means that if someone manages to mess with your disk
and then cause you to reboot, it's pretty close to game-over.  But one
of the advantages is that it wouldn't rely on the host administrator to
install your introspection engine -- you could have a cloud provider
simply expose the altp2m functionality, and then each person could have
their own in-guest agent as they want.

And although arguably the in-guest agent is less secure from *being*
attacked, it does mean that the system as a whole is more secure.
Having an agent in dom0 means that if you compromise the dom0 agent, you
now have complete access to the entire system; whereas compromising your
in-guest agent gives you only control over that guest, no other guests
on the system.

> The in-guest agent should in our view be an optimization-only, not
> something allowed to make its own decisions about the introspection process.

I think having an interface which allows an only-in-guest-agent makes
sense -- particularly as one instance has already been made.  If it were
entirely up to me, I'd leave the interface, so that it's there for
someone later to pick up if they want to.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel