GCC 15 Adds Option For Arm Guarded Control Stack "GCS" Code Generation

[phoronix]

Phoronix: GCC 15 Adds Option For Arm Guarded Control Stack "GCS" Code Generation

GCC 15 feature development is soon wrapping up to focus on bug fixing before releasing GCC 15.1 as stable in the early months of 2025. One of the latest features to make it in the compiler codebase is code generation support around Arm Guarded Control Stack (GCS) functionality...

https://www.phoronix.com/news/GCC-15-Arm-GCS-Code-Generation

[kylew77]

I wonder what it's real effect on security will be? Not that it will be trivial to bypass it but if it will stop a lot of attacks.

[stormcrow]

I wonder what it's real effect on security will be? Not that it will be trivial to bypass it but if it will stop a lot of attacks.

I've only the barest understanding of ROP (Return Oriented Programming) as I'm not a programmer myself, but I'm going to take a stab at it anyway and others with more information on the matter can correct me or expand on it.

First, the linked quote isn't really the Arm documentation, rather it's the Arm Blog summarizing some architectural changes in v9's ISA. It doesn't cite any real world example code it intends to protect against. I assume there's examples in the mentioned, but not linked-to from the blog, developer documentation.

"A GCS is a protected region of virtual address space allocated by software. When the processor executes a Branch with Link instruction, such as BL, the return address is pushed onto the GCS as well as being written into the Link Register (LR). On a procedure return, the latest stored return address is popped from the GCS. The processor either compares the popped value with the LR, or uses the popped value directly...To prevent accidental or malicious changes to the GCS, a new Stage 1 permission is introduced. This permission allows reads by software, but restricts writes to either GCSPUSH instructions or as a side-effect of executing a BL."

ROP is an advanced living off the land technique that generally requires some targeting of the unique execution environment they're trying to exploit. One is looking for specific sequences of function/returns already present in memory, then searching among them for exploitable flaws that can be manipulated into popping up a privileged shell or privileged command execution chain. The section of the quote in bold is the important part of GCS. It theoretically prevents writing to the memory address contained in the targeted function's memory space thereby preventing manipulation of the flaw. The flaw still exists, but it can't be exploited in this manner. Read-only access is theoretically hardware enforced. You'll probably see a access violation error followed by a crash instead of exploitation.

I'm not going to opine on how trivial it could be to get around the GCS because I'm not qualified to do so.

[sp00nz]

So basically the same as Shadow Stack on x86? (implemented in recent AMD & Intel CPUs but still not enabled by default on just about any Linux distro afaik, though seemingly close with the ABI now locked down & support in glibc)

I wonder what it's real effect on security will be? Not that it will be trivial to bypass it but if it will stop a lot of attacks.

I've wondered that too -- for example, what percentage of recent CVEs (that are result of attacks on code like buffer overflows etc) are completely neutralized by ROP & COP/JOP protections.

[ssokolow]

I wonder what it's real effect on security will be? Not that it will be trivial to bypass it but if it will stop a lot of attacks.

It really depends. Some pages claim that 90% of exploits these days use ROP, but then you also have this post which is claiming that ROP is already on the way out.