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 >>>>> <[email protected]> wrote: >>>>>> On 07/05/2018 07:45 PM, Tamas K Lengyel wrote: >>>>>>> On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru >>>>>>> <[email protected]> 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. Best, ~Sergej _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
