From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"minipli@grsecurity.net" <minipli@grsecurity.net>,
"tglx@kernel.org" <tglx@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] x86/shstk: Provide kernel command line knob to disable
Date: Wed, 6 May 2026 22:45:13 +0000 [thread overview]
Message-ID: <4cffee5d2886129e621d3011db1d00a236869d1d.camel@intel.com> (raw)
In-Reply-To: <739e4dd0-84a3-4b37-8cc3-b7ec59737010@intel.com>
On Wed, 2026-05-06 at 12:03 -0700, Dave Hansen wrote:
> Is there a reason that clearcpuid=shstk doesn't work in this case? I
> guess shstk and ibt are peers, but I was kinda hoping we'd stop adding
> these for every single CPU feature at _some_ point.
Oh yea, for the reason of "debugging related issues during early boot"
clearcpuid of shstk and ibt should be fine. It taints the kernel, but should be
fine for debugging? If I'm reading this right, the kernel does the clearcpuid
processing before setting up CET bits.
I'm remembering we actually already have a "nousershstk" too, which covers the
"userspace init cet violations break boot" usage.
What that doesn't do though, is clear CR4.CET. With nousershstk, KVM can still
use CET. So that is what is missing. A way to clear CR4.CET without tainting the
kernel when HW supports CET. Do we need it?
prev parent reply other threads:[~2026-05-06 22:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 17:36 [PATCH v2] x86/shstk: Provide kernel command line knob to disable Mathias Krause
2026-05-04 12:09 ` Mathias Krause
2026-05-06 19:03 ` Dave Hansen
2026-05-06 22:45 ` Edgecombe, Rick P [this message]
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=4cffee5d2886129e621d3011db1d00a236869d1d.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=minipli@grsecurity.net \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox