linux-hardening - Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy configuration and violation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zl5f_T7Nb-Fk8Y1o@google.com>
Date: Mon, 3 Jun 2024 17:29:49 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: "Mickaël Salaün" <mic@...ikod.net>
Cc: Nicolas Saenz Julienne <nsaenz@...zon.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H . Peter Anvin" <hpa@...or.com>, 
	Ingo Molnar <mingo@...hat.com>, Kees Cook <keescook@...omium.org>, 
	Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>, Wanpeng Li <wanpengli@...cent.com>, 
	Rick P Edgecombe <rick.p.edgecombe@...el.com>, Alexander Graf <graf@...zon.com>, 
	Angelina Vu <angelinavu@...ux.microsoft.com>, 
	Anna Trikalinou <atrikalinou@...rosoft.com>, Chao Peng <chao.p.peng@...ux.intel.com>, 
	Forrest Yuan Yu <yuanyu@...gle.com>, James Gowans <jgowans@...zon.com>, 
	James Morris <jamorris@...ux.microsoft.com>, John Andersen <john.s.andersen@...el.com>, 
	"Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>, Marian Rotariu <marian.c.rotariu@...il.com>, 
	"Mihai Donțu" <mdontu@...defender.com>, 
	"Nicușor Cîțu" <nicu.citu@...oud.com>, Thara Gopinath <tgopinath@...rosoft.com>, 
	Trilok Soni <quic_tsoni@...cinc.com>, Wei Liu <wei.liu@...nel.org>, 
	Will Deacon <will@...nel.org>, Yu Zhang <yu.c.zhang@...ux.intel.com>, 
	"Ștefan Șicleru" <ssicleru@...defender.com>, dev@...ts.cloudhypervisor.org, 
	kvm@...r.kernel.org, linux-hardening@...r.kernel.org, 
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, qemu-devel@...gnu.org, 
	virtualization@...ts.linux-foundation.org, x86@...nel.org, 
	xen-devel@...ts.xenproject.org
Subject: Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy
 configuration and violation

On Tue, May 14, 2024, Mickaël Salaün wrote:
> On Tue, May 07, 2024 at 09:16:06AM -0700, Sean Christopherson wrote:
> > On Tue, May 07, 2024, Mickaël Salaün wrote:
> > > If yes, that would indeed require a *lot* of work for something we're not
> > > sure will be accepted later on.
> > 
> > Yes and no.  The AWS folks are pursuing VSM support in KVM+QEMU, and SVSM support
> > is trending toward the paired VM+vCPU model.  IMO, it's entirely feasible to
> > design KVM support such that much of the development load can be shared between
> > the projects.  And having 2+ use cases for a feature (set) makes it _much_ more
> > likely that the feature(s) will be accepted.
> > 
> > And similar to what Paolo said regarding HEKI not having a complete story, I
> > don't see a clear line of sight for landing host-defined policy enforcement, as
> > there are many open, non-trivial questions that need answers. I.e. upstreaming
> > HEKI in its current form is also far from a done deal, and isn't guaranteed to
> > be substantially less work when all is said and done.
> 
> I'm not sure to understand why "Heki not having a complete story".  The
> goal is the same as the current kernel self-protection mechanisms.

HEKI doesn't have a complete story for how it's going to play nice with kexec(),
emulated RESET, etc.  The kernel's existing self-protection mechanisms Just Work
because the protections are automatically disabled/lost on such transitions.
They are obviously significant drawbacks to that behavior, but they are accepted
drawbacks, i.e. solving those problems isn't in scope (yet) for the kernel.  And
the "failure" mode is also loss of hardening, not an unusable guest.

In other words, the kernel's hardening is firmly best effort at this time,
whereas HEKI likely needs to be much more than "best effort" in order to justify
the extra complexity.  And that means having answers to the various interoperability
questions.