[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <069a9c63-3cb4-4fc4-9566-bfffb6d07cc5@sirena.org.uk>
Date: Wed, 4 Jun 2025 12:05:25 +0100
From: Mark Brown <broonie@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Yury Khrustalev <yury.khrustalev@....com>, linux-kernel@...r.kernel.org,
Christian Brauner <brauner@...nel.org>,
Mark Rutland <mark.rutland@....com>, linux-api@...r.kernel.org
Subject: Re: Extending clone_args for clone3()
On Wed, Jun 04, 2025 at 10:29:48AM +0200, Arnd Bergmann wrote:
> As I understand the shadow stack feature, we want this to be enabled
> whenever the kernel and hardware supports it, completely transparent
> to an application, right?
Slightly more involved, but roughly. The application and all libraries
linked into it should be built targeting shadow stacks (most binaries
will already be compatible but it's possible they wouldn't be so we
can't just asssume that) then if everything is compatible shadow stacks
will be enabled transparently by libc if the system supports them.
> I think ideally we'd check for HWCAP_GCS on arm64 or the equivalent
> feature on other architectures and expect clone3 to support the
> longer argument whenever that is set, but it looks like that would
> break on current kernels that already support HWCAP_GCS but not
> the clone3 argument.
> Adding one more hwcap flag would be ugly, but that seems to be
> the easiest way. That way, glibc can just test for the new hwcap
> flag only use the extra clone3 word if all prerequisites (hardware
> support, kernel gcs support, clone3 argument support) are there.
We'd also have to add something similar for x86 since that's had the
support even longer, and the RISC-V series looks like it's getting near
to being merged too so we'll likely have the same problem there given
that the clone3() series is not progressing super fast.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists