[RFC 2/5] aarch64: check if clone3 supports shadow stack

[Catalin Marinas]

On Tue, Jun 10, 2025 at 07:14:12PM +0100, Mark Brown wrote:
> On Tue, Jun 10, 2025 at 02:34:28PM -0300, Adhemerval Zanella Netto wrote:
> > On 10/06/25 12:13, Yury Khrustalev wrote:
> 
> Adding Catalin.

Thanks. A similar thread here, also cc'ing the people on the other
thread:

https://lore.kernel.org/lkml/aCs65ccRQtJBnZ_5@arm.com/

> > > Rely on the version of the currently running kernel and use
> > > existing mechanism to determine this version (same that was
> > > used for checks related to SVE).
> 
> > Since this is WIP feature, this would be simpler if kernel advertise it through
> > a new HWCAP bits.  The kernel parsing is somewhat fragile and thinking
> > twice we should have done it as well for the SVE issue that required to add
> > this back on 2e94e2f5d2bf2de124c8ad7da85463355e54ccb2.
> 
> > The powerpc did a similar thing with PPC_FEATURE2_HTM_NOSC to avoid some
> > performance issues with the initial HTM enablement on pthread (which made
> > us tune it better, check f0458cf4f9ff3d870c43b624e6dccaaf657d5e83).
> 
> That's technically easy enough to do on arm64 and did come up before,
> it's just mildly annoying.  The main reason I held off was that this
> also affects x86 (which has had shadow stack support for even longer)
> and at current rate of progress likely also RISC-V so a per arch thing
> didn't seem ideal.  I'll need to investigate what the tasteful thing is
> on x86.
> 
> It does also feel like we should have a better solution for clone3() in
> general...

I'm not keen on having a HWCAP just to tell whether clone3() supports
the shadow stack arguments. This feels fairly generic (or at least for
x86, arm64 and soon risc-v) and not specific to a hardware feature,
especially as we already advertise HWCAP_GCS.

In hindsight, we could have waited for clone3() support to go in
together with HWCAP_GCS on arm64 but it wouldn't have solved a similar
problem on x86.

Would it be feasible to probe clone3() for E2BIG, either separately or
when creating a thread, together with a fallback to clone2() and caching
the support state?

Alternatively, I'd rather have an AT_ entry, it feels more generic than
arch-specific HWCAP bit.

-- 
Catalin