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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

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.

Awesome, +1 for modifying it so that it can be called from
dom0/privileged domain!

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

With the modification you are planning, even this could be just a
DOMCTL. There is no need for the guest to call that as long as the
external agent can figure out what page to use for #VE.

>
> 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?

+1 from me!

Thanks,
Tamas

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