From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "x86@kernel.org" <x86@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"ripatel@wii.dev" <ripatel@wii.dev>,
"tglx@kernel.org" <tglx@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Cc: "hpa@zytor.com" <hpa@zytor.com>,
"kees@kernel.org" <kees@kernel.org>,
"shuah@kernel.org" <shuah@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH 0/3] x86/shstk: ban ia32 sigreturn
Date: Thu, 8 Oct 2026 21:00:14 +0000 [thread overview]
Message-ID: <2aa256e2547087f3551a6340a99e2cad103ff3d0.camel@intel.com> (raw)
In-Reply-To: <20261008201610.1003569-1-ripatel@wii.dev>
On Thu, 2026-10-08 at 20:16 +0000, Richard Patel wrote:
> (This scenario is basically
> impossible to occur in the wild, but it's probably worth fixing
> nonetheless.)
The original purpose of limiting it at all vs just leaving it unimplemented was
to not have to think through the implications. Since there was an easy way to
dissuade almost all usage, it was closed. If it will require plugging a bunch of
loose ends then I think the cost/benefit needs to be revisited.
I'd also wonder if we couldn't do a shadow stack check in do_int80_emulation()
vs for each syscall that might grow shadow stack behavior someday.
prev parent reply other threads:[~2026-10-08 21:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 20:16 Richard Patel
2026-10-08 20:16 ` [PATCH 1/3] x86/shstk: ban ia32 sigreturn when shadow stack is enabled Richard Patel
2026-10-08 20:59 ` Edgecombe, Rick P
2026-10-08 21:50 ` Richard Patel
2026-10-08 22:34 ` Edgecombe, Rick P
2026-10-08 22:47 ` Richard Patel
2026-10-08 23:11 ` Edgecombe, Rick P
2026-10-08 23:29 ` Richard Patel
2026-10-09 11:36 ` Richard Patel
2026-10-08 20:16 ` [PATCH 2/3] selftests/x86: test shadow stack sigreturn protection Richard Patel
2026-10-08 20:16 ` [PATCH 3/3] selftests/x86: skip shstk tests where perf_event_open() fails Richard Patel
2026-10-08 21:00 ` 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=2aa256e2547087f3551a6340a99e2cad103ff3d0.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ripatel@wii.dev \
--cc=shuah@kernel.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
all inboxes | Powered by JetHome®