On Thu, Jul 06, 2023 at 04:59:45PM +0000, Edgecombe, Rick P wrote: > On Thu, 2023-07-06 at 15:24 +0100, Mark Brown wrote: > > szabolcs.nagy@xxxxxxx wrote: > > > The 07/05/2023 20:29, Mark Brown wrote: > > > gcspopm is always available (esentially *ssp++, this is used > > > for longjmp). > > Ah, sorry - I misremembered there. You're right, it's only push that > > we > > have control over. FWIW the confusion there was some of the hypervisor features which do tie some of the push and pop instructions together. > Ah, ok! So if you are not planning to enable the push mode then the > features are pretty well aligned, except: > - On x86 it is possible to switch stacks without leaving a token > behind. > - The GCSPOPM/INCSSP looping may require longer loops on ARM > because it only pops one at at time. > If you are not going to use GCSPUSHM by default, then I think we > *should* be able to have some unified set of rules for developers for > glibc behaviors at least. Yes, the only case where I am aware of conciously diverging in any substantial way is that we do not free the GCS when GCS is disabled by userspace, we just disable the updates and checks, and reenabling after disabling is not supported. We have demand for disabling at runtime so we want to keep the stack around for things like a running unwinder but we don't see a practical use for reenabling so didn't worry about figuring out what would make sense for userspace. glibc isn't going to be using that though.
Attachment:
signature.asc
Description: PGP signature
