Hi James, On Fri, Jul 17, 2026 at 10:35:10AM -0400, James Bottomley wrote: > So this all depends how the planes are started. If you're starting > them from an IGVM file that loads the most privileged code and then > runs the guest in a different plane, absolutely, it can work as you > describe. However, the common use case for serviceable security > enclaves is you start the kernel first (necessarily in plane 0) and > then bring up the enclaves later which means the planes > 0 are > technically higher privilege since they're running hidden security > code. HOWEVER, there's no reason at all to trust a security enclave > that's doing something like guarding private keys to be able to poke > anywhere it wants in the guest ... that's a security breach waiting to > happen, so it would really be better if the model were not > hierarchical, but more akin to the ability to seal planes off from each > other, so the kernel can start the enclave, which would then set itself > and the communication area up, but then the plane 0 kernel would remove > access to most memory from the enclave. > > In this sealing model, there's no absolute privilege levels; each plane > would decide what the other planes can see of its memory space and, on > security grounds, we'd likely configure the enclaves to have the least > possible privilege. > > Now, Windows applications expect VSM to be strictly hierarchical in > terms of privilege, but if we create a sealing primitive as described > above, we can get it to build the strict VSM privilege hierarchy in the > hyper-v driver.
I mostly agree with this and have to say that my statement in the cover letter about plane hierarchies was a bit broad. The main assumption this patch-set makes about plane 0 is that it is the plane which does the IRQ scheduling. Say a VM has Plane 0,1, and 2. A VCPU runs plane 2 and KVM wants to inject an IRQ into plane 1 of that VCPU. Now KVM needs the VCPU to decide whether it wants to run plane 1 to handle the IRQ or continue with plane 2 because it currently has higher-priority work to do. This decision is made on plane 0 in this patch-set, which it needs to be for VMPLs. Does VSM have a similar concept for IRQ scheduling between VTLs or will the hypervisor take care to run a VTL when it has IRQs? -Joerg
