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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZCXotrLbDl6JJaVj@google.com>
Date:   Thu, 30 Mar 2023 13:05:27 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     John Allen <john.allen@....com>, g@...gle.com
Cc:     Weijiang Yang <weijiang.yang@...el.com>,
        "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 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.