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: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.

Hence, Tamas has come up with the config files restrictions allowing
those HVMOPs to be called only from dom0, and our decision to basically
disable in-guest access and call them all only from dom0.

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


Thanks,
Razvan

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