On Tue, Aug 01, 2023 at 04:09:58PM +0100, Mark Brown wrote: > On Tue, Aug 01, 2023 at 03:13:20PM +0100, Will Deacon wrote: > > On Mon, Jul 31, 2023 at 02:43:09PM +0100, Mark Brown wrote: > > > > The arm64 Guarded Control Stack (GCS) feature provides support for > > > hardware protected stacks of return addresses, intended to provide > > > hardening against return oriented programming (ROP) attacks and to make > > > it easier to gather call stacks for applications such as profiling. > > > Why is this better than Clang's software shadow stack implementation? It > > would be nice to see some justification behind adding all this, rather > > than it being an architectural tick-box exercise. > > Mainly that it's hardware enforced (as the quoted paragraph says). This > makes it harder to attack, and hopefully it's also a bit faster (how > measurable that might be will be an open question, but even NOPs in > function entry/exit tend to get noticed). I dunno, "hardware enforced" can also mean worse security nowadays ;) But seriously, I think the question is more about what this brings us *on top of* SCS, since for the forseeable future folks that care about this stuff (like Android) will be using SCS. GCS on its own doesn't make sense to me, given the recompilation effort to remove SCS and the lack of hardware, so then you have to look at what it brings in addition to GCS and balance that against the performance cost. Given that, is anybody planning to ship a distribution with this enabled? If not, why are we bothering? If so, how much of that distribution has been brought up and how does the "dynamic linker or other startup code" decide what to do? After the mess we had with BTI and mprotect(), I'm hesitant to merge features like this without knowing that the ABI can stand real code. Will
