That is Apple silicon specific (at least for now?) as it isn’t a behaviour inherent to the ISA but rather it is yet another cache related side channel. It is of course entirely possible that other vendors will have the same info leak, but that particular paper seemed to be only interested in Apple hardware - I’m unsure how widely deployed PAC is in other vendor hardware so don’t know how feasible testing is.

[edit: this is also a 2017 article (I hadn't realized originally, cheers @dmytrish) so the gcc, etc support comments are presumably outdated]

The "SafeStack" [1] scheme is probably the most well-known that does that. The "safe" stack is the normal stack, and the "unsafe" stack contains all automatic variables that could get dereferenced - including arrays that could overflow. The security of the scheme depends on keeping the location of the safe stack secret, which for one thing means that all code in the program needs to use the SafeStack ABI. It is used more or less in several BSD Unices (most notably HardenedBSD), and it is the default in Fuchsia (except when the program was written in Go).

CPU architectures that have register windows [2] tend to spill shifted-out registers onto a separate stack lazily, and those registers could contain the return pointer.

[1] <https://clang.llvm.org/docs/SafeStack.html>

[2] <https://en.wikipedia.org/wiki/Register_window>

ARM pointer authentication can be used for all pointers. Shadow stacks only protect against overwriting the return pointer.