The 07/28/2020 20:59, Catalin Marinas wrote: > On Tue, Jul 28, 2020 at 03:53:51PM +0100, Szabolcs Nagy wrote: > > if linux does not want to add a per process > > setting then only libc will be able to opt-in > > to mte and only at very early in the startup > > process (before executing any user code that > > may start threads). this is not out of question, > > but i think it limits the usage and deployment > > options. > > There is also the risk that we try to be too flexible at this stage > without a real use-case. i don't know how mte will be turned on in libc. if we can always turn sync tag checks on early whenever mte is available then i think there is no issue. but if we have to make the decision later for compatibility or performance reasons then per thread setting is problematic. use of the prctl outside of libc is very limited if it's per thread only: - application code may use it in a (elf specific) pre-initialization function, but that's a bit obscure (not exposed in c) and it is reasonable for an application to enable mte checks after it registered a signal handler for mte faults. (and at that point it may be multi-threaded). - library code normally initializes per thread state on the first call into the library from a given thread, but with mte, as soon as memory / pointers are tagged in one thread, all threads are affected: not performing checks in other threads is less secure (may be ok) and it means incompatible syscall abi (not ok). so at least PR_TAGGED_ADDR_ENABLE should have process wide setting for this usage. but i guess it is fine to design the mechanism for these in a later linux version, until then such usage will be unreliable (will depend on how early threads are created).
