From: Mark Brown <broonie@kernel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>,
"brauner@kernel.org" <brauner@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"mgorman@suse.de" <mgorman@suse.de>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"vschneid@redhat.com" <vschneid@redhat.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"bristot@redhat.com" <bristot@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"bsegall@google.com" <bsegall@google.com>,
"x86@kernel.org" <x86@kernel.org>,
"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"jannh@google.com" <jannh@google.com>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"will@kernel.org" <will@kernel.org>
Subject: Re: [PATCH RFT v4 5/5] kselftest/clone3: Test shadow stack support
Date: Tue, 5 Dec 2023 15:05:36 +0000 [thread overview]
Message-ID: <345cf31a-3663-4974-9b2a-54d2433e64a7@sirena.org.uk> (raw)
In-Reply-To: <4898975452179af46f38daa6979b32ba94001419.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
On Tue, Dec 05, 2023 at 12:10:20AM +0000, Edgecombe, Rick P wrote:
> Without this diff, the test crashed for me on a shadow stack system:
> -static inline void enable_shadow_stack(void)
> +static inline __attribute__((always_inline)) void
doh.
> But I wonder if the clone3 test should get its shadow stack enabled the
> conventional elf bit way. So if it's all there (HW, kernel, glibc) then
> the test will run with shadow stack. Otherwise the test will run
> without shadow stack.
This creates bootstrapping issues if we do it for arm64 where nothing is
merged yet except for the model and EL3 support - in order to get any
test coverage you need to be using an OS with the libc and toolchain
support available and that's not going to be something we can rely on
for a while (and even when things are merged a lot of the CI systems use
Debian). There is a small risk that the toolchain will generate
incompatible code if it doesn't know it's specifically targetting shadow
stacks but the toolchain people didn't seem concerned about that risk
and we've not been running into problems.
It looks x86 is in better shape here with the userspace having run ahead
of the kernel support though I'm not 100% clear if everything is fully
lined up? -mshstk -fcf-protection appears to build fine with gcc 8 but
I'm a bit less clear on glibc and any ABI variations.
> The other reason is that the shadow stack test in the x86 selftest
> manual enabling is designed to work without a shadow stack enabled
> glibc and has to be specially crafted to work around the missing
> support. I'm not sure the more generic selftests should have to know
> how to do this. So what about something like this instead:
What's the issue with working around the missing support? My
understanding was that there should be no ill effects from repeated
attempts to enable. We could add a check for things already being
enabled
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-12-05 15:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 18:22 [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3() Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 2/5] fork: Add shadow stack support to clone3() Mark Brown
2023-11-28 21:23 ` Deepak Gupta
2023-11-29 13:05 ` Mark Brown
2023-12-05 0:26 ` Edgecombe, Rick P
2023-12-05 15:51 ` Mark Brown
2023-12-05 22:23 ` Edgecombe, Rick P
2023-12-06 18:24 ` Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 3/5] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 4/5] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 5/5] kselftest/clone3: Test shadow stack support Mark Brown
2023-12-05 0:10 ` Edgecombe, Rick P
2023-12-05 15:05 ` Mark Brown [this message]
2023-12-05 16:01 ` Edgecombe, Rick P
2023-12-05 16:43 ` Mark Brown
2023-12-05 22:31 ` Edgecombe, Rick P
2023-12-06 18:42 ` Mark Brown
2023-11-30 19:00 ` [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3() Catalin Marinas
2023-11-30 21:51 ` Mark Brown
2023-11-30 23:37 ` Edgecombe, Rick P
2023-12-01 14:00 ` Mark Brown
2023-12-01 11:50 ` Szabolcs Nagy
2023-12-01 13:47 ` Mark Brown
2023-12-01 17:30 ` Catalin Marinas
2023-12-01 18:28 ` Mark Brown
2023-12-09 0:59 ` Robert O'Callahan
2023-12-09 1:06 ` Mark Brown
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=345cf31a-3663-4974-9b2a-54d2433e64a7@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Szabolcs.Nagy@arm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=debug@rivosinc.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).