[AAPCS64] AAPCS64 should specify minimal requirements for setjmp and longjmp for memory tagging

[yury-khrustalev]

The MemTagABIELF64 extension provides recommendations for operating systems such as Linux. There are some implementation details related to DT_AARCH64_MEMTAG_STACK that should also be specified but are out of scope of the MemTagABIELF64 document.

The implementation of stack tagging is left to the compiler, however the implementation of setjmp and longjmp is out of scope of a compiler. There should be a description of minimal requirements that complying implementations of setjmp and longjmp as well as complying implementations of stack tagging in a compiler should abide by.

At least there should be a way for the implementation of setjmp and longjmp to determine if any extra operations related to stack memory tagging should be skipped so that the same binary implementation in a runtime that provides setjmp and longjmp (e.g. Glibc) could work for binaries with and without support for stack tagging.

[yury-khrustalev]

Hello @enh and @cferris, would you be interested in discussing this issue? Thanks!

[enh-google]

what's the actual question here?

[yury-khrustalev]

@enh-google, I just want to get some agreement-in-principle (from stakeholders of the MEMTAG ABI document) that we should add requirements for setjmp and longjmp that all implementations of stack tagging should abide by with. I can then create a patch for AAPCS64. There was previously some push-back for making changes to the MEMTAG ABI spec or adding GNU/Linux related specifics.

[enh-google]

@enh-google, I just want to get some agreement-in-principle (from stakeholders of the MEMTAG ABI document) that we should add requirements for setjmp and longjmp that all implementations of stack tagging should abide by with. I can then create a patch for AAPCS64. There was previously some push-back for making changes to the MEMTAG ABI spec or adding GNU/Linux related specifics.

do you have examples of what kind of requirements you have in mind? none of the different implementations are binary compatible anyway, so i'm not sure what you mean?

in the abstract, i suspect the recent SME-related setjmp/longjmp mess is a signal that there's probably a need for arm-specific documentation somewhere --- not that it would have avoided the mess, since the problem there was that no-one really understood what needed to be done, so no-one could have written it down, but having it written down would at least help any future implementations...

[yury-khrustalev]

none of the different implementations are binary compatible anyway, so i'm not sure what you mean?

This is exactly the issue that I'm trying to solve. Stack tagging is implemented by the compiler while setjmp and longjmp are provided by a libc (e.g. Glibc). There can be multiple compiler implementations of stack tagging, and programs using it may run with different libcs.

• Is it possible to make it all work by imposing some basic ABI rules on compiler implementation?
• Can the same Glibc binary support programs with and without stack tagging?

I don't know, but I'd like to find a way and write it down in the spec, at least for the scope of GNU/Linux.

in the abstract, i suspect the recent SME-related setjmp/longjmp mess is a signal that there's probably a need for arm-specific documentation somewhere

Yes, this is why I created this issue to have this discussed.

[enh-google]

maybe clearest to upload the specific recommendations you're thinking about, and then worry about where exactly they should go afterwards?

is there a prototype of the compiler side yet?

[yury-khrustalev]

is there a prototype of the compiler side yet?

Yes, there are implementations in GCC and LLVM.

maybe clearest to upload the specific recommendations you're thinking about

I don't have a solution yet, not even a draft. However, this is the example of the problem that I'd like to resolve. As explained in the commit message for this Glibc patch, there are cases when tagged memory on stack needs to be additionally processed in some way to prevent false tag check errors, e.g. for setjmp and longjmp.

The situation is similar to GCS where we needed to add extra code to these functions to ensure correctness of the state of the (shadow) stack. With GCS it was easy because there is a way to perform a very quick runtime check to understand if this extra processing is actually required. This way, the same Glibc binary can work on targets with and without GCS support and run GCS and non-GCS programs.

The Glibc patch linked above relies on a custom build configuration and would not be portable.

One way to overcome this would be, perhaps, to require compilers to supply a flag (and maybe even more information such as size of the tagged memory in a frame that needs to be untagged) that can be used to in functions like longjmp to know what and when needs to be done. But like I said, at the moment, I don't have a good solution.