Re: [RFC PATCH 0/7] SVM guest shadow stack support

[Yang, Weijiang]

On 3/31/2023 4:05 AM, Sean Christopherson wrote:
> On Thu, Mar 30, 2023, John Allen wrote:
> > On Thu, Mar 30, 2023 at 01:37:38PM +0800, Yang, Weijiang wrote:
> > > 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).
> > > Patch 1/7 did what I wanted to implement to support AMD SHSTK, my next
> > > version will continue refactoring them in vmx scope, then� your series may
> > > pick up the helper and modify accordingly.
> > >
> > > Please note, in my series, I removed check for MSR_IA32_PL{0,1,2}_SSP since
> > > 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.
> > 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
> And emulating/virtualizing those MSRs is mandatory unless KVM can hide those MSRs
> without violating the architecture (been a while since I looked at CET).  If the
> architecture does allow enumerating support for userspace but not supervisor, then
> ideally the two would be enabled separately in KVM, e.g. so that that if one is
> completely busted, we might be able to precisely revert only the broken code.

OK, I'll add a separate patch to expose these supervisor MSRs but they 
are not accessible on Intel

platform right now, i.e., resulting into #GP.

Meanwhile CPUID(7,1).EDX.bit 18 is always cleared to tell guest 
supervisor SHSTK is not supported.

Allen can modify per AMD needs.