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

["Yang, Weijiang" <weijiang.yang@intel.com>]

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.