Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 30 Mar 2023 13:05:27 -0700
In-Reply-To: <ZCXnYj3GsoB1Kipo@johallen-workstation.lan>
Mime-Version: 1.0
References: <20221012203910.204793-1-john.allen@amd.com> <Y9B97dZnFnjEHhVf@google.com>
 <d4e15021af4e72d6daba4021feaebf289b676830.camel@intel.com>
 <ZCMpJLAx8//1zLLV@johallen-workstation.lan> <b75c6f20-a99c-a6d4-c1c1-7ae9f016d2af@intel.com>
 <9cf73a9d-d9eb-c6a6-a083-88539a3e78a2@intel.com> <ZCXnYj3GsoB1Kipo@johallen-workstation.lan>
Message-ID: <ZCXotrLbDl6JJaVj@google.com>
Subject: Re: [RFC PATCH 0/7] SVM guest shadow stack support
From:   Sean Christopherson <seanjc@google.com>
To:     John Allen <john.allen@amd.com>, g@google.com
Cc:     Weijiang Yang <weijiang.yang@intel.com>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "x86@kernel.org" <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Mar 30, 2023, John Allen wrote:
> On Thu, Mar 30, 2023 at 01:37:38PM +0800, Yang, Weijiang wrote:
> >=20
> > On 3/29/2023 8:16 AM, Yang, Weijiang wrote:
> > > > Now that the baremetal series has been accepted, how do we want to
> > > > proceed? I think I'd like to send a refreshed version based on the
> > > > version that was accpeted, but I'd want to wait to base it on a new
> > > > version of Weijiang's kvm/vmx series (if one is planned).
> >=20
> > Patch 1/7 did what I wanted to implement to support AMD SHSTK, my next
> > version will continue refactoring them in vmx scope, then=EF=BF=BD your=
 series may
> > pick up the helper and modify accordingly.
> >=20
> > Please note, in my series, I removed check for MSR_IA32_PL{0,1,2}_SSP s=
ince
> > they're not supported right now, but your series supports for the MSRs,=
 so
> > you have to change the helper a bit to adapt to your patches.
>=20
> The reason we decided to include the PL{0,1,2}_SSP MSRs is that even
> though linux doesn't support supervisor shadow stack, a non-linux guest
> OS might support it and could make use of the MSRs. It could be
> something the vmx patches might want to account for as well=20

And emulating/virtualizing those MSRs is mandatory unless KVM can hide thos=
e MSRs
without violating the architecture (been a while since I looked at CET).  I=
f the
architecture does allow enumerating support for userspace but not superviso=
r, then
ideally the two would be enabled separately in KVM, e.g. so that that if on=
e is
completely busted, we might be able to precisely revert only the broken cod=
e.