LWN: Comments on "Shadow stacks for 64-bit Arm systems"

Enforcing no-ROP breaks ABI

broonie — Thu, 17 Aug 2023 20:42:11 +0000

The expectation is that as with BTI the dynamic loader will look at ELF markings to determine if the binaries it is linking support GCS, and there will probably be an override mechanism with something like environment variables too. In any case it's entirely in userspace.

Enforcing no-ROP breaks ABI

timon — Thu, 17 Aug 2023 11:19:40 +0000

From the article:

> [...] the expectation is that the shadow stack will be enabled in the dynamic loader before jumping to a program's entry point [...]

My understading would then be that apps might actually run with shadow stacks enabled without knowing of their existence. Or maybe I'm wrong, and shadow stack support will require recompilation in any case.

Enforcing no-ROP breaks ABI

jepsis — Thu, 17 Aug 2023 10:14:48 +0000

"I anticipate the crashing of hundreds of apps with thousands of installations."

Why? Have those apps set PR_SET_SHADOW_STACK_STATUS with PR_SHADOW_STACK_ENABLE flag without knowing their existence? Most probably not.

Shadow stacks for 64-bit Arm systems

dxin — Thu, 17 Aug 2023 03:43:13 +0000

That totally defeats the purpose of having single letter extensions, i.e. to cascade them into feature sets e.g. G=IMAFD.

Enforcing no-ROP breaks ABI

jreiser — Sun, 13 Aug 2023 20:14:58 +0000

[no-ROP is a ban on Return-Oriented Programming]

> Whenever a function call is made, the current return address is pushed onto both
> the regular stack and the shadow stack. When the function returns, the addresses at the top
> of the two stacks are compared; if they do not match, the system concludes that the call stack
> has been corrupted and, probably, aborts execution.

If that is enforced strictly, then it breaks the user-mode ABI. I anticipate the crashing of hundreds of apps with thousands of installations. I wrote those apps. More precisely, I wrote the ELF side of UPX. which compresses an ELF module (main program or shared library) into smaller space (typically 30% to 60% less) but retains the same external behavior. The self-contained execution stub which quickly expands the compressed module into RAM, back to its original layout, uses ROP in places because ROP is smaller than any other method. Cache misses from any hardware return-address [prediction] cache are ignored in favor of fewer bytes of code and less complexity.

On x86*, if the observable semantic behavior of a CALL instruction is anything other than {*--sp = next_ip; goto target;}, or a RET(URN) instruction is anything other than {goto *sp++;}, then that breaks the architectural ABI of the CPU. If you want something more, then you should get a different opcode.

In general, ROP can be a valuable technique for implementing a generator, emulator, or interpreter, especially in small space. ROP is a hardware implementation of direct threaded code. At first, storage space in many current systems may appear to be effectively infinite; yet complaints such as “another song/photo/video/app/backup won’t fit” seem never to disappear.

Shadow stacks for 64-bit Arm systems

rwmj — Thu, 10 Aug 2023 10:50:26 +0000

In case you're wondering why the RISC-V extensions will be called "Zicfiss" and "Zicfilp", here is why:

RISC-V extensions were originally single letters, like "I" for ISA base, "A" for Atomic and so on. Which worked well until predictably they ran out of letters. The new convention is Z + most closely related extension + name.

So Zicfiss is Z + i (closely related to normal baseline instructions) + name "cfiss" for control flow integrity shadow stack. Zicfilp is the same but "landing pad".

Is "zisslpcfi" from the article an earlier version of the extension name? The latest extension docs don't seem to refer to it: https://github.com/riscv/riscv-cfi/blob/main/riscv-cfi.pdf