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

[Sean Christopherson <seanjc@google.com>]

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.