From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
James Morris <jamorris@linux.microsoft.com>
Cc: kvm@vger.kernel.org,
Thara Gopinath <tgopinath@linux.microsoft.com>,
mic@digikod.net
Subject: Re: 2024 HEKI discussion: LPC microconf / KVM Forum?
Date: Sat, 04 May 2024 03:10:33 +0200 [thread overview]
Message-ID: <F301C3DE-2248-4E73-B694-07DC4FB6AE80@redhat.com> (raw)
In-Reply-To: <ZjV0vXZJJ2_2p8gz@google.com>
Il 4 maggio 2024 01:35:25 CEST, Sean Christopherson <seanjc@google.com> 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
next prev parent reply other threads:[~2024-05-04 1:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 17:30 2024 HEKI discussion: LPC microconf / KVM Forum? James Morris
2024-05-03 23:35 ` Sean Christopherson
2024-05-04 1:10 ` Paolo Bonzini [this message]
2024-05-06 18:26 ` Mickaël Salaün
2024-05-07 0:02 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F301C3DE-2248-4E73-B694-07DC4FB6AE80@redhat.com \
--to=pbonzini@redhat.com \
--cc=jamorris@linux.microsoft.com \
--cc=kvm@vger.kernel.org \
--cc=mic@digikod.net \
--cc=seanjc@google.com \
--cc=tgopinath@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).