Re: [PATCH 35/60] kvm: Add VCPU plane-scheduling state and helpers

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2026-06-09 at 14:37 +0200, Jörg Rödel wrote:
> I read a bit more about VSM and it seems their prioritization of VTLs
> is a bit more complicated. VTL0 has the least privileges but boots
> first, then sets up VTL1. But VTL1 is only higher-privileged once it
> is locked by VTL0. Another way to look at it is that VTL0 de-
> prioritizes itself.

Actually, I don't think we have to follow the VSM model.  All we at
Microsoft care about is that we can emulate VSM with the planes
primitives provided.

There's a definite reason not to do strict VTL privilege in that one
can see two mutually distrusting planes sharing a common communication
area.  This is definitely possible with TDX and so planes shouldn't
disallow it.

> The patches here are built around the assumption that plane0 is the
> highest privileged one and is always runnable. Running any lower-
> privilege plane must be triggered by the guest. This is clearly not
> sufficient for VSM, the question is how to solve that.

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.

Regards,

James