On Wed, 2023-07-05 at 20:10 +0100, Mark Brown wrote: > On Wed, Jul 05, 2023 at 06:45:38PM +0000, Edgecombe, Rick P wrote: > > > Looking at the docs Mark linked (thanks!), ARM has generic GCS PUSH > > and > > POP shadow stack instructions? Can ARM just push a restore token at > > setjmp time, like I was trying to figure out earlier with a push > > token > > arch_prctl? It would be good to understand how ARM is going to > > implement this with these differences in what is allowed by the HW. > > > If there are differences in how locked down/functional the hardware > > implementations are, and if we want to have some unified set of > > rules > > for apps, there will need to some give and take. The x86 approach > > was > > mostly to not support all behaviors and ask apps to either change > > or > > not enable shadow stacks. We don't want one architecture to have to > > do > > a bunch of strange things, but we also don't want one to lose some > > key > > end user value. > > GCS is all or nothing, either the hardware supports GCS or it > doesn't. > There are finer grained hypervisor traps (see HFGxTR_EL2 in the > system > registers) but they aren't intended to be used to disable partial > functionality and there's a strong chance we'd just disable the > feature > in the face of such usage. The kernel does have the option to > control > which functionality is exposed to userspace, in particular we have > separate controls for use of the GCS, the push/pop instructions and > the > store instructions (similarly to the control x86 has for WRSS). > Similarly to the handling of WRSS in your series my patches allow > userspace to choose which of these features are enabled. Ah, interesting, thanks for the extra info. So which features is glibc planning to use? (probably more of a question for Szabolcs). Are push and pop controllable separately?
