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. Pinning CR0/CR4 bits is fine and okay it helps for SMEP/SMAP/WP, but it's not the interesting part. 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. 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. 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. Paolo
