[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 07/09/2018 02:46 PM, George Dunlap wrote:
> 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.

That is all well argued, and is fair enough.

All I was really trying to point out was that we're happy with either
DOMCTL or HVMOPs for this (and it looks like Tamas as well) - the actual
point is to just try and settle this once for all so that altp2m
development can go forward (because really at this point its de-facto
blocked for unreasonably long ammounts of time by the design debate, on
every patch adding or modifying an operation).

Obviously actual users of a full-in-guest agent changes things - in
which case the HVMOPs likely need to remain HVMOPs if for no other
reason but to remain compatible with those users.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.