2024 HEKI discussion: LPC microconf / KVM Forum?

2024 HEKI discussion: LPC microconf / KVM Forum?

[James Morris]

Hi Folks,

We are planning our travel & conference submissions and I'm wondering if 
there is likely to be an LPC KVM microconf again this year. And if so, 
what would be the best option for proposing an update on the HEKI 
(hypervisor enforced kernel integrity) project?

We'd like to demonstrate where we're at with the project and discuss next 
steps with the community, in terms of both core kernel changes and the 
KVM-specific project work.


As a reference, here are the LPC sessions from 2023:
- KVM microconf: https://lpc.events/event/17/contributions/1486/
- Main track overview: https://lpc.events/event/17/contributions/1515/



-- 
James Morris
<jamorris@linux.microsoft.com>

Re: 2024 HEKI discussion: LPC microconf / KVM Forum?

[Sean Christopherson]

On Wed, May 01, 2024, James Morris wrote:
> Hi Folks,
> 
> We are planning our travel & conference submissions and I'm wondering if 
> there is likely to be an LPC KVM microconf again this year.

There is, thanks for the reminder to send out an announcement[1]!  :-)

> And if so, what would be the best option for proposing an update on the HEKI
> (hypervisor enforced kernel integrity) project?
> 
> We'd like to demonstrate where we're at with the project and discuss next 
> steps with the community, in terms of both core kernel changes and the 
> KVM-specific project work.

Proposals/abstracts can be submitted via the web portal.  Though to be perfectly
honest, for where HEKI is at from an upstream KVM perspective, and especially if
you want to provide an update, then I think KVM Forum[2] would be a better fit.
(I haven't seen an official announcment/CFP for KVM Forum, but the web site is
live, so I assume it's a done deal).

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

[1] https://lore.kernel.org/all/20240503231845.1287764-1-seanjc@google.com
[2] https://kvm-forum.qemu.org
[3] https://lore.kernel.org/all/20230512231026.799267-1-seanjc@google.com

Re: 2024 HEKI discussion: LPC microconf / KVM Forum?

[Paolo Bonzini]

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

Re: 2024 HEKI discussion: LPC microconf / KVM Forum?

[Mickaël Salaün]

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!

Re: 2024 HEKI discussion: LPC microconf / KVM Forum?

[Sean Christopherson]

On Mon, May 06, 2024, Mickaël Salaün wrote:
> 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.

Hmm, I'm probably getting my streams crossed and/or misremembering entirely.