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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Mon, Jul 9, 2018 at 8:50 AM Sergej Proskurin <proskurin@xxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> as I am currently working on a concept that uses the #VE functionality
> from inside of the unprivileged guest domain myself, I would like to add
> my opinion to the discussion.
>
>
> On 07/09/2018 07:53 AM, Razvan Cojocaru wrote:
> > 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?
>
> I absolutely agree upon that Intel was building a system that allows
> guest domains to enable and control the #VE (including the funcitonality
> to set up different altp2ms). Although this functionality has not been
> widely adopted (yet?), I personally would prefer a hybrid solution that
> does not completely prohibit this concept from inside of the
> unprivileged guest domain. I agree with Tamas upon the fact that some
> concepts can be equally implemented by using the guest's page tables
> only. However, (I understand that I am biased, as I am working on a
> concept that makes use of this functionality from inside of domu), I
> also believe that we can apply the functionality given by #VE and VMFUNC
> from inside the guest to harden certain system resources. As such, I
> would be happy to see a hybrid solution that allows this feature to be
> configured either for unlimited or for external use only.

Thanks for the input Sergej. With that and George pointing out other
users of the in-guest use-case we can't just do the switch. Letting
people decide using the existing domain config option / XSM what way
they want to have the interface accessible is not the worst thing in
the world. Introducing further, more restricted in-guest accessible
modes could be done potentially in the future that only allows the #VE
page-setup op to go through - if there is a need for it.

Tamas

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