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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Wed Jun 11 16:15:46 GMT 2025



On 11/06/25 11:02, Yury Khrustalev wrote:
> On Tue, Jun 10, 2025 at 02:34:28PM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 10/06/25 12:13, Yury Khrustalev wrote:
>>> 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 we only need this information in certain case, we try
>>> to guard this additional code with macros and extra flag.
>>> ...
>>>
>> 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
> 
> I agree that it's fragile, I only used it to facilitate building and testing
> of this patch series.
> 
>> 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).
> 
> 
> HWCAP or AT_ value in auxv could be a solution, but they require some
> thinking through because it's easy to do a stopgap fix and then have even
> more issues in the future.

IMHO it should the kernel to advertise any extra require handling in userspace
process management through a direct way, instead of userland to trying to 
figure out through indirect way (kernel version parsing, procfs/sysfs, etc).

The kernel parsing also some extra overhead on all process execution.

> 
> Looking at other extensions of struct clone_args in the past, I see that
> it's happened a couple of times, however the new fields are not used in
> Glibc, so we've never had this issue before.
> 
> One exception is the cgroup field that is used by posix_spawn() and friends.
> However, the implementation doesn't check for E2BIG after clone3 syscall,
> so we seem to ignore possibility of an error here.
There is no need yet to handle E2BIG because posix_spawn we only need
to use clone3 for posix_spawn_file_actions_addtcsetpgrp_np and kernel
will return EINVAL for invalid flags (CLONE_INTO_CGROUP).

And the need to handle E2BIG will really depend of which ABI will
export to the callers, because on most cases we now try to avoid
add fallback support when there is no direct kernel access.  The
CLONE_CLEAR_SIGHAND is an option that we can safely apply if the kernel
does not support it; but other option (like cgroup itself) the best
option is just to return an error.


More information about the Libc-alpha mailing list