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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ