On Sat, May 04, 2024 at 03:10:33AM GMT, Paolo Bonzini wrote: > > > Il 4 maggio 2024 01:35:25 CEST, Sean Christopherson <seanjc@xxxxxxxxxx> ha scritto: > >The most contentious aspects of HEKI are the guest changes, not the KVM changes. > >The KVM uAPI and guest ABI will require some discussion, but I don't anticipate > >those being truly hard problems to solve. > > I am not sure I agree... The problem with HEKI as of last November was that it's not clear what it protects against. What's the attack and how it's prevented. The initial goal of Heki is to "duplicate" the guest's kernel self protections in a higher level privilege component (i.e. the hypervisor), and potentially to make it possible to add new protections. > Pinning CR0/CR4 bits is fine and okay it helps for SMEP/SMAP/WP, but it's not the interesting part. I though we agree that we need to start with something small and incrementally build on top of that, hence this patch series [1]. [1] https://lore.kernel.org/r/20240503131910.307630-1-mic@xxxxxxxxxxx > > For example, it is nice to store all the kernel text in memory that is not writable except during module loading and patching, but it doesn't add much to the security of the system if writability is just a hypercall away. So for example you could map the module loading and patching code so that it has access to read-only data (enforced by the hypervisor system-wide) but on the other hand can write to the kernel text. Exactly, that's why we implemented immutability for the guest to only be able to add more constraints to itself. This is still the case for the new CR-pinning patch series. However, as you mention, we also need to handle dynamic memory changes such as module loading. We are actively working on this and we have promising results. Madhavan can explain in more details but I think it would be wise to delay that discussion when we'll send a dedicated patch series and when we'll have agree on the current CR-pinning one. > > So a potential API could be: > - a hypercall to register a key to be used for future authentication > - a hypercall to copy something to that region of memory only if the data passes some HMAC or signature algorithm > - introduce a VTL-like mechanism for permissions on a region of memory, e.g.: memory that is never writable except from more privileged code (kernel text), memory that is never writable except through a hypercall. > > And that is not necessarily a good idea or even something implementable :) but at least it has an attack model and a strategy to prevent it > > Otherwise the alternative would be to use VTLs for Linux and adopt a similar API in KVM. That is more generic, but it is probably even more controversial for guest side changes and therefore it needs even more a clear justification of the attack model and how it's mitigated. Because Hyper-V has VTLs, we implemented the same protections on Hyper-V with this mechanism. There is not such thing with KVM (and other hypervisors), and we'd like to implement practical protection not relying on hypothetical future features. If/when KVM get a feature similar to VTLs, we could then use it for some advanced protections. Anyway, as mentioned by Sean, KVM's userspace still need to manage/control a big part of the guest protection, at least the CR-pinning and memory permission, and this would probably not change with VTLs but only add more complexity. At the end I think the current hypercall and VM exit interfaces, enhanced with full userspace control as requested by Sean, are good. What do you think? > > Paolo > > > And if you really want to get HEKI > >moving, I would advise you not wait until September to hash out the KVM side of > >things, e.g. I'd be more than happy to talk about HEKI in a PUCK[3] session. Sure!
