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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8e8e2885-22c4-46f4-ba25-943fedd11319@intel.com>
Date:   Fri, 31 Mar 2023 14:39:26 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        John Allen <john.allen@....com>
CC:     "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: Re: [RFC PATCH 0/7] SVM guest shadow stack support


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.