|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page
On 07/09/2018 12:53 PM, 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? >>> >>> The wording on their initial design document does say: >>> >>> "- Hypercalls for altp2m >>> >>> Altp2m mode introduces a new set of hypercalls for altp2m management >>> from software agents operating in Xen HVM guests. >>> >>> The hypercalls are as follows: >>> >>> Enable or Disable altp2m mode for domain >>> Create a new alternate p2m >>> Edit permissions for a specific GPA within an alternate p2m >>> Destroy an existing alternate p2m" >>> >>> But I've always suspected that it might have been just what they have >>> thought would offer the most possibilities. >>> >>> The problem with in-guest agents doing all these things is that it kind >>> of kills the whole "the introspection cannot be stopped or manipulated >>> at all from within the guest" assumption that gives hypervisor-level >>> introspection its edge - because then it's possible for in-guest code to >>> bypass dom0-based introspection by simply switching to a non-restricted >>> EPTP index, or editing the restricted pages permissions. And we're back >>> to in-guest protection. >> >> I don't think you've quite gotten the design in mind here. The idea is >> that *all* of the "introspection" happens inside the guest. The guest >> agent is given all the tools it needs to protect itself even from the >> guest operating system. Just having a chat with Andy, apparently Intel >> actually had just such an agent once upon a time, and used this >> interface on Xen for real. >> >> I think there are advantages to each model. Obviously having something >> run in the guest means that if someone manages to mess with your disk >> and then cause you to reboot, it's pretty close to game-over. But one >> of the advantages is that it wouldn't rely on the host administrator to >> install your introspection engine -- you could have a cloud provider >> simply expose the altp2m functionality, and then each person could have >> their own in-guest agent as they want. >> >> And although arguably the in-guest agent is less secure from *being* >> attacked, it does mean that the system as a whole is more secure. >> Having an agent in dom0 means that if you compromise the dom0 agent, you >> now have complete access to the entire system; whereas compromising your >> in-guest agent gives you only control over that guest, no other guests >> on the system. >> >>> The in-guest agent should in our view be an optimization-only, not >>> something allowed to make its own decisions about the introspection process. >> >> I think having an interface which allows an only-in-guest-agent makes >> sense -- particularly as one instance has already been made. If it were >> entirely up to me, I'd leave the interface, so that it's there for >> someone later to pick up if they want to. > > That is all well argued, and is fair enough. > > All I was really trying to point out was that we're happy with either > DOMCTL or HVMOPs for this (and it looks like Tamas as well) - the actual > point is to just try and settle this once for all so that altp2m > development can go forward (because really at this point its de-facto > blocked for unreasonably long ammounts of time by the design debate, on > every patch adding or modifying an operation). Sure, it's certainly unpleasant, and unfair, every time you want to extend the interface for your own use case, to get into a big argument about what should happen with respect to some other use case, which not only *you* aren't using, but it would seem, *nobody* at the moment is using. And I remember now, the last time this came up you wanted to add a new subop, and Jan said it should be a domctl unless we knew we wanted to expose it to the guest, and Andy said it should be with all the other functionality (i.e., an hvmop). This is just silly. We already decided they should all be HVMOPs. If we want to disable ALTP2M_mixed mode until someone wants to audit it -- or whitelist only the curret functionality -- that's one thing. But we shouldn't make a second hypercall for non-guest-accessible functionality, nor should we even consider changing the current HVMOP into a DOMCTL. Absolutely not. We do need to stop having pointless arguments, however. Let me see what I can come up with. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |