KVM Archive mirror
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>,
	 James Morris <jamorris@linux.microsoft.com>,
	kvm@vger.kernel.org,
	 Thara Gopinath <tgopinath@linux.microsoft.com>,
	"Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
Subject: Re: 2024 HEKI discussion: LPC microconf / KVM Forum?
Date: Mon, 6 May 2024 20:26:38 +0200	[thread overview]
Message-ID: <20240506.eBegohcheM0a@digikod.net> (raw)
In-Reply-To: <F301C3DE-2248-4E73-B694-07DC4FB6AE80@redhat.com>

On Sat, May 04, 2024 at 03:10:33AM GMT, Paolo Bonzini wrote:
> 
> 
> 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.

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@digikod.net

> 
> 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!

  reply	other threads:[~2024-05-06 18:26 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
2024-05-06 18:26     ` Mickaël Salaün [this message]
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=20240506.eBegohcheM0a@digikod.net \
    --to=mic@digikod.net \
    --cc=jamorris@linux.microsoft.com \
    --cc=kvm@vger.kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=pbonzini@redhat.com \
    --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).