On Fri, Aug 18, 2023 at 08:38:02PM +0100, Mark Brown wrote: > On Fri, Aug 18, 2023 at 06:29:54PM +0100, Catalin Marinas wrote: > > A related question - it may have been discussed intensively on the x86 > > thread (I may read it sometime) - why not have the libc map the shadow > > Your assumption that this is a single thread feels optimistic there. Yeah and I unfortunately ignored all of them. > > stack and pass the pointer/size to clone3()? It saves us from having to > > guess what the right size we'd need. struct clone_args is extensible. > > I can't recall or locate the specific reasoning there right now, perhaps > Rick or someone else can? I'd guess there would be compat concerns for > things that don't go via libc which would complicate the story with > identifying and marking things as GCS/SS safe, it's going to be more > robust to just supply a GCS if the process is using it. That said > having a default doesn't preclude us using the extensibility to allow > userspace directly to control the GCS size, I would certainly be in > favour of adding support for that. It would be good if someone provided a summary of the x86 decision (I'll get to those thread but most likely in September). I think we concluded that we can't deploy GCS entirely transparently, so we need a libc change (apart from the ELF annotations). Since libc is opting in to GCS, we could also update the pthread_create() etc. to allocate the shadow together with the standard stack. Anyway, that's my preference but maybe there were good reasons not to do this. -- Catalin
