Why speculate? Measure and see.
Conversation
I have a Zen 3 CPU (Ryzen 9 5950X) with CET shadow stack support although I don't think it has CET coarse grained CFI support. I don't think I can measure anything because userspace CET SS support for Linux isn't upstream and I doubt Zen 3 has an optimized implementation anyway.
1
Not really interested in trying experimental userspace CET SS patches and then figuring out if the support included in GCC/Clang and glibc even works properly.
I know how Clang/GCC SSP, Clang CFI and Clang SCS perform on various CPUs but no clue about CET or ARM PAC/BTI/MTE.
1
Wild to me that linux doesn’t have proper support for cet yet. Windows had it when those cpus launched.
1
1
Intel had it written a long time ago but they have to appease a bunch of people who are close to having absolute veto power over their parts of the kernel unless Linus decides that something is important needs to land which mostly isn't going to happen for security features.
1
They have to go through dozens of iterations of the patches primarily to try to appease all kinds of subjective and often questionable / conflicting demands. Stuff tends to end up being overall higher quality by the end but sometimes things end up worse for political reasons.
1
It's pretty common for features to take ages to end up in the upstream kernel. Pixel phones use Clang CFI and SCS in the kernel for the Pixel 3 and later. Neither of those features is available in mainline Linux yet. Pixel 3 launched in November 2018 with CFI (got SCS later).
1
1
You can boot Android with mainline Linux kernels but there are a bunch of optional performance, security and other enhancements that are missing including things that are required for shipping devices by the CTS/CDD. It just takes ages to land that kind of stuff upstream...
1
As an example, I got Android to start using perf_event_paranoid=3 which is enabled by default and then lowered by Android Studio via ADB (requires enabling it in developer options, having physical access and approving key) to perf_event_paranoid=2 for developers using profiling.
1
perf_event_paranoid=3 has been hard rejected by the upstream Linux perf maintainers because they want perf profiling to be universally available and used in JIT compilers, etc. instead of doing their own tracing. They strongly dislike that Android disallows it by default.
1
1
Android now tries to use BPF and seccomp-bpf to implement features even when it makes it much more complex than changing the kernel code directly.
~6k LOC userspace / BPF code replaced gid-based socket perms needing ~26 LOC in the kernel and a couple lines of xml in userspace.