[PATCH v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks
Catalin Marinas
catalin.marinas at arm.com
Tue Aug 22 09:49:51 PDT 2023
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
More information about the linux-riscv
mailing list