On Tue, May 14, 2024, Mickaël Salaün wrote: > On Tue, May 07, 2024 at 09:16:06AM -0700, Sean Christopherson wrote: > > On Tue, May 07, 2024, Mickaël Salaün wrote: > > > If yes, that would indeed require a *lot* of work for something we're not > > > sure will be accepted later on. > > > > Yes and no. The AWS folks are pursuing VSM support in KVM+QEMU, and SVSM > > support > > is trending toward the paired VM+vCPU model. IMO, it's entirely feasible to > > design KVM support such that much of the development load can be shared > > between > > the projects. And having 2+ use cases for a feature (set) makes it _much_ > > more > > likely that the feature(s) will be accepted. > > > > And similar to what Paolo said regarding HEKI not having a complete story, I > > don't see a clear line of sight for landing host-defined policy > > enforcement, as > > there are many open, non-trivial questions that need answers. I.e. > > upstreaming > > HEKI in its current form is also far from a done deal, and isn't guaranteed > > to > > be substantially less work when all is said and done. > > I'm not sure to understand why "Heki not having a complete story". The > goal is the same as the current kernel self-protection mechanisms.
HEKI doesn't have a complete story for how it's going to play nice with kexec(), emulated RESET, etc. The kernel's existing self-protection mechanisms Just Work because the protections are automatically disabled/lost on such transitions. They are obviously significant drawbacks to that behavior, but they are accepted drawbacks, i.e. solving those problems isn't in scope (yet) for the kernel. And the "failure" mode is also loss of hardening, not an unusable guest. In other words, the kernel's hardening is firmly best effort at this time, whereas HEKI likely needs to be much more than "best effort" in order to justify the extra complexity. And that means having answers to the various interoperability questions.
