[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D15VQ97L5M8J.1TDNQE6KLW6JO@amazon.com>
Date: Fri, 10 May 2024 10:07:00 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Sean Christopherson <seanjc@...gle.com>,
Mickaël Salaün <mic@...ikod.net>
CC: 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 7, 2024 at 4:16 PM UTC, Sean Christopherson 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.
Since Sean mentioned our VSM efforts, a small update. We were able to
validate the concept of one KVM VM per VTL as discussed in LPC. Right
now only for single CPU guests, but are in the late stages of bringing
up MP support. The resulting KVM code is small, and most will be
uncontroversial (I hope). If other obligations allow it, we plan on
having something suitable for review in the coming months.
Our implementation aims to implement all the VSM spec necessary to run
with Microsoft Credential Guard. But note that some aspects necessary
for HVCI are not covered, especially the ones that depend on MBEC
support, or some categories of secure intercepts.
Development happens
https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next
branch, but I'd advice against looking into it until we add some order
to the rework. Regardless, feel free to get in touch.
Nicolas
Powered by blists - more mailing lists