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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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.

So at the moment we neither need nor use _any_ HVMOP from the guest (but
it does make sense that the guest be able to do
HVMOP_altp2m_vcpu_enable_notify indeed).

So it would appear that at least at this time, for both us and Tamas the
only operation that needs to be a HVMOP is HVMOP_altp2m_vcpu_enable_notify.

In that case, if everyone agrees, I propose that we make all the others
DOMCTLs. This would also have several maintenance benefits:

1. We can then get rid of the ugly compat code that was required for
upstreaming xc_altp2m_set_mem_access_multi() (and clean up the
hypervisor code corresponding to it).

2. We can probably remove Tamas' patch that controls if dom0, the guest,
or both can call altp2m operations (although maybe we should keep it for
the one remaining HVMOP? I'm not sure).

So to my mind, it's less, cleaner, safer code. I don't see how the
original designers of the code would object, since their goal I would
assume was helping introspection, and Tamas and us are the ones trying
to use it - furthermore these changes address the security objections of
the Xen community.

Does the plan sound reasonable?


Thanks,
Razvan

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