All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "peterz@infradead.org" <peterz@infradead.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
	"x86@kernel.org" <x86@kernel.org>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"Yang, Weijiang" <weijiang.yang@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH 03/19] x86/cpufeatures: Enable CET CR4 bit for shadow stack
Date: Fri, 17 Jun 2022 21:18:47 +0000	[thread overview]
Message-ID: <b1d4d26144e933382a92425164f78367ff92aea5.camel@intel.com> (raw)
In-Reply-To: <YqxnwRn+/c+i1vL6@worktop.programming.kicks-ass.net>

+kexec people

On Fri, 2022-06-17 at 13:38 +0200, Peter Zijlstra wrote:
> On Thu, Jun 16, 2022 at 05:12:47PM +0000, Edgecombe, Rick P wrote:
> > On Thu, 2022-06-16 at 12:24 +0200, Peter Zijlstra wrote:
> > > On Thu, Jun 16, 2022 at 04:46:27AM -0400, Yang Weijiang wrote:
> > > > --- a/arch/x86/include/asm/cpu.h
> > > > +++ b/arch/x86/include/asm/cpu.h
> > > > @@ -74,7 +74,7 @@ void init_ia32_feat_ctl(struct cpuinfo_x86
> > > > *c);
> > > >    static inline void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
> > > > {}
> > > >    #endif
> > > >    
> > > > -extern __noendbr void cet_disable(void);
> > > > +extern __noendbr void ibt_disable(void);
> > > >    
> > > >    struct ucode_cpu_info;
> > > >    
> > > > diff --git a/arch/x86/kernel/cpu/common.c
> > > > b/arch/x86/kernel/cpu/common.c
> > > > index c296cb1c0113..86102a8d451e 100644
> > > > --- a/arch/x86/kernel/cpu/common.c
> > > > +++ b/arch/x86/kernel/cpu/common.c
> > > > @@ -598,23 +598,23 @@ __noendbr void ibt_restore(u64 save)
> > > >    
> > > > -__noendbr void cet_disable(void)
> > > > +__noendbr void ibt_disable(void)
> > > >    {
> > > >         if (cpu_feature_enabled(X86_FEATURE_IBT))
> > > >                 wrmsrl(MSR_IA32_S_CET, 0);
> > > 
> > > Not sure about this rename; it really disables all of (S) CET.
> > > 
> > > Specifically, once we do S-SHSTK (after FRED) we might also very
> > > much
> > > need to kill that for kexec.
> > 
> > Sure, what about something like sup_cet_disable()?
> 
> Why bother? Arguably kexec should clear U_CET too.

Hmm, I think you're right. It doesn't look the fpu stuff actually would
reset unknown xfeatures to init. So kernels with Kernel IBT would set
CR4.CET and then MSR_IA32_U_CET might make it to the point where
userspace would run with CET enabled.

It seems like a general kexec problem for when the kernel enables new
xfeatures. I suppose having vector instruction type data stick around
is not going to show up the same way as having new enforcement rules
applied.

But also, looking at this, the existing clearing of MSR_IA32_S_CET is
not sufficient, since it only does it on the cpu doing the kexec. I
think something like the below might be needed. Since per the other
discussion we are going to need to start setting CR4.CET whenever the
HW supports it, for KVM's benefit. So those other CPUs might get
supervisor IBT enabled if we don't clear the msr from every CPU.

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9730c88530fc..eb57d7f4fa6a 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -96,6 +96,12 @@ static void kdump_nmi_callback(int cpu, struct
pt_regs *regs)
        cpu_emergency_stop_pt();
 
        disable_local_APIC();
+
+       /*
+        * Make sure to disable CET features before kexec so the new
kernel
+        * doesn't get surprised by the enforcement.
+        */
+       cet_disable();
 }
 
 void kdump_nmi_shootdown_cpus(void)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 738226472468..de65bac0ae02 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -787,6 +787,12 @@ void __noreturn stop_this_cpu(void *dummy)
         */
        if (cpuid_eax(0x8000001f) & BIT(0))
                native_wbinvd();
+
+       /*
+        * Make sure to disable CET features before kexec so the new
kernel
+        * doesn't get surprised by the enforcement.
+        */
+       cet_disable();
        for (;;) {
                /*
                 * Use native_halt() so that memory contents don't
change

WARNING: multiple messages have this Message-ID (diff)
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "peterz@infradead.org" <peterz@infradead.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
	"x86@kernel.org" <x86@kernel.org>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"Yang, Weijiang" <weijiang.yang@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH 03/19] x86/cpufeatures: Enable CET CR4 bit for shadow stack
Date: Fri, 17 Jun 2022 21:18:47 +0000	[thread overview]
Message-ID: <b1d4d26144e933382a92425164f78367ff92aea5.camel@intel.com> (raw)
In-Reply-To: <YqxnwRn+/c+i1vL6@worktop.programming.kicks-ass.net>

+kexec people

On Fri, 2022-06-17 at 13:38 +0200, Peter Zijlstra wrote:
> On Thu, Jun 16, 2022 at 05:12:47PM +0000, Edgecombe, Rick P wrote:
> > On Thu, 2022-06-16 at 12:24 +0200, Peter Zijlstra wrote:
> > > On Thu, Jun 16, 2022 at 04:46:27AM -0400, Yang Weijiang wrote:
> > > > --- a/arch/x86/include/asm/cpu.h
> > > > +++ b/arch/x86/include/asm/cpu.h
> > > > @@ -74,7 +74,7 @@ void init_ia32_feat_ctl(struct cpuinfo_x86
> > > > *c);
> > > >    static inline void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
> > > > {}
> > > >    #endif
> > > >    
> > > > -extern __noendbr void cet_disable(void);
> > > > +extern __noendbr void ibt_disable(void);
> > > >    
> > > >    struct ucode_cpu_info;
> > > >    
> > > > diff --git a/arch/x86/kernel/cpu/common.c
> > > > b/arch/x86/kernel/cpu/common.c
> > > > index c296cb1c0113..86102a8d451e 100644
> > > > --- a/arch/x86/kernel/cpu/common.c
> > > > +++ b/arch/x86/kernel/cpu/common.c
> > > > @@ -598,23 +598,23 @@ __noendbr void ibt_restore(u64 save)
> > > >    
> > > > -__noendbr void cet_disable(void)
> > > > +__noendbr void ibt_disable(void)
> > > >    {
> > > >         if (cpu_feature_enabled(X86_FEATURE_IBT))
> > > >                 wrmsrl(MSR_IA32_S_CET, 0);
> > > 
> > > Not sure about this rename; it really disables all of (S) CET.
> > > 
> > > Specifically, once we do S-SHSTK (after FRED) we might also very
> > > much
> > > need to kill that for kexec.
> > 
> > Sure, what about something like sup_cet_disable()?
> 
> Why bother? Arguably kexec should clear U_CET too.

Hmm, I think you're right. It doesn't look the fpu stuff actually would
reset unknown xfeatures to init. So kernels with Kernel IBT would set
CR4.CET and then MSR_IA32_U_CET might make it to the point where
userspace would run with CET enabled.

It seems like a general kexec problem for when the kernel enables new
xfeatures. I suppose having vector instruction type data stick around
is not going to show up the same way as having new enforcement rules
applied.

But also, looking at this, the existing clearing of MSR_IA32_S_CET is
not sufficient, since it only does it on the cpu doing the kexec. I
think something like the below might be needed. Since per the other
discussion we are going to need to start setting CR4.CET whenever the
HW supports it, for KVM's benefit. So those other CPUs might get
supervisor IBT enabled if we don't clear the msr from every CPU.

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9730c88530fc..eb57d7f4fa6a 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -96,6 +96,12 @@ static void kdump_nmi_callback(int cpu, struct
pt_regs *regs)
        cpu_emergency_stop_pt();
 
        disable_local_APIC();
+
+       /*
+        * Make sure to disable CET features before kexec so the new
kernel
+        * doesn't get surprised by the enforcement.
+        */
+       cet_disable();
 }
 
 void kdump_nmi_shootdown_cpus(void)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 738226472468..de65bac0ae02 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -787,6 +787,12 @@ void __noreturn stop_this_cpu(void *dummy)
         */
        if (cpuid_eax(0x8000001f) & BIT(0))
                native_wbinvd();
+
+       /*
+        * Make sure to disable CET features before kexec so the new
kernel
+        * doesn't get surprised by the enforcement.
+        */
+       cet_disable();
        for (;;) {
                /*
                 * Use native_halt() so that memory contents don't
change
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2022-06-17 21:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16  8:46 [PATCH 00/19] Refresh queued CET virtualization series Yang Weijiang
2022-06-16  8:46 ` [PATCH 01/19] x86/cet/shstk: Add Kconfig option for Shadow Stack Yang Weijiang
2022-06-16  8:46 ` [PATCH 02/19] x86/cpufeatures: Add CPU feature flags for shadow stacks Yang Weijiang
2022-06-16  8:46 ` [PATCH 03/19] x86/cpufeatures: Enable CET CR4 bit for shadow stack Yang Weijiang
2022-06-16 10:24   ` Peter Zijlstra
2022-06-16 17:12     ` Edgecombe, Rick P
2022-06-17 11:38       ` Peter Zijlstra
2022-06-17 21:18         ` Edgecombe, Rick P [this message]
2022-06-17 21:18           ` Edgecombe, Rick P
2022-06-16 10:25   ` Peter Zijlstra
2022-06-16 17:36     ` Edgecombe, Rick P
2022-06-16  8:46 ` [PATCH 04/19] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Yang Weijiang
2022-06-16 10:27   ` Peter Zijlstra
2022-06-16 17:12     ` Edgecombe, Rick P
2022-06-16  8:46 ` [PATCH 05/19] x86/fpu: Add helper for modifying xstate Yang Weijiang
2022-06-16  8:46 ` [PATCH 06/19] KVM: x86: Report XSS as an MSR to be saved if there are supported features Yang Weijiang
2022-06-16  8:46 ` [PATCH 07/19] KVM: x86: Refresh CPUID on writes to MSR_IA32_XSS Yang Weijiang
2022-06-16  8:46 ` [PATCH 08/19] KVM: x86: Load guest fpu state when accessing MSRs managed by XSAVES Yang Weijiang
2022-06-16  8:46 ` [PATCH 09/19] KVM: x86: Add #CP support in guest exception classification Yang Weijiang
2022-06-16  8:46 ` [PATCH 10/19] KVM: VMX: Introduce CET VMCS fields and flags Yang Weijiang
2022-06-16  8:46 ` [PATCH 11/19] KVM: x86: Add fault checks for CR4.CET Yang Weijiang
2022-06-16  8:46 ` [PATCH 12/19] KVM: VMX: Emulate reads and writes to CET MSRs Yang Weijiang
2022-06-16  8:46 ` [PATCH 13/19] KVM: VMX: Add a synthetic MSR to allow userspace VMM to access GUEST_SSP Yang Weijiang
2022-06-16  8:46 ` [PATCH 14/19] KVM: x86: Report CET MSRs as to-be-saved if CET is supported Yang Weijiang
2022-06-16  8:46 ` [PATCH 15/19] KVM: x86: Save/Restore GUEST_SSP to/from SMM state save area Yang Weijiang
2022-06-16  8:46 ` [PATCH 16/19] KVM: x86: Enable CET virtualization for VMX and advertise CET to userspace Yang Weijiang
2022-06-16 10:59   ` Peter Zijlstra
2022-06-16 15:27     ` Yang, Weijiang
2022-06-25  6:55     ` Yang, Weijiang
2022-06-16  8:46 ` [PATCH 17/19] KVM: VMX: Pass through CET MSRs to the guest when supported Yang Weijiang
2022-06-16  8:46 ` [PATCH 18/19] KVM: nVMX: Enable CET support for nested VMX Yang Weijiang
2022-06-16  8:46 ` [PATCH 19/19] KVM: x86: Enable supervisor IBT support for guest Yang Weijiang
2022-06-16 11:05   ` Peter Zijlstra
2022-06-16 11:19   ` Peter Zijlstra
2022-06-16 15:56     ` Yang, Weijiang
2022-06-16  9:10 ` [PATCH 00/19] Refresh queued CET virtualization series Christoph Hellwig
2022-06-16 11:25   ` Peter Zijlstra
2022-06-16 10:12 ` Peter Zijlstra
2022-06-16 10:21   ` Paolo Bonzini
2022-06-16 14:18     ` Peter Zijlstra
2022-06-16 15:06       ` Yang, Weijiang
2022-06-16 15:28       ` Paolo Bonzini
2022-06-18  6:43         ` Yang, Weijiang
2022-07-14 19:36           ` Sean Christopherson
2022-07-15 15:04             ` Yang, Weijiang
2022-07-15 15:58               ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1d4d26144e933382a92425164f78367ff92aea5.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --cc=weijiang.yang@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.