On 07/06/2018 05:52 PM, Tamas K Lengyel wrote: > On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru > <rcojoc...@bitdefender.com> wrote: >> >> On 07/05/2018 07:45 PM, Tamas K Lengyel wrote: >>> On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru >>> <rcojoc...@bitdefender.com> 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? >> 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! I don't have much skin in this particular game -- my main goal in these discussions (other than keeping Xen well-designed and reasonably secure) has been to keep contributors happy. If you guys are happy, and Intel doesn't express any opinions, then I have no objections. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
