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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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.


Thanks,
Razvan

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