adding libc-alpha on cc, they might have additional input about compat issue handling: the discussion is about enabling tag checks, which cannot be done reasonably at runtime when a process is already multi-threaded so it has to be decided early either in the libc or in the kernel. such early decision might have backward compat issues (we dont yet know if any allocator wants to use tagging opportunistically later for debugging or if there will be code loaded later that is incompatible with tag checks). The 08/19/2020 10:54, Catalin Marinas wrote: > On Wed, Aug 12, 2020 at 01:45:21PM +0100, Szabolcs Nagy wrote: > > On 08/11/2020 18:20, Catalin Marinas wrote: > > > If we allow such mixed object support with stack tagging enabled at > > > dlopen, PROT_MTE would need to be turned on for each thread stack. This > > > wouldn't require synchronisation, only knowing where the thread stacks > > > are, but you'd need to make sure threads don't call into the new library > > > until the stacks have been mprotect'ed. Doing this midway through a > > > function execution may corrupt the tags. ... > > there is no midway problem: the libc (ld.so) would do the PROT_MTE at > > dlopen time based on some elf marking (which can be handled before > > relocation processing, so before library code can run, the midway > > problem happens when a library, e.g libc, wants to turn on stack > > tagging on itself). > > OK, that makes sense, you can't call into the new object until the > relocations have been resolved. > > > the libc already does this when a library is loaded that requires > > executable stack (it marks stacks as PROT_EXEC at dlopen time or fails > > the dlopen if that is not possible, this does not require running code > > in other threads, only synchronization with thread creation and exit. > > but changing the check mode for mte needs per thread code execution.). > > > > i'm not entirely sure if this is a good idea, but i expect stack > > tagging not to be used in the libc (because libc needs to run on all > > hw and we don't yet have a backward compatible stack tagging > > solution), > > In theory, you could have two libc deployed in your distro and ldd gets > smarter to pick the right one. I still hope we'd find a compromise with > stack tagging and single binary. distros don't like the two libc solution, i think we will look at backward compat stack tagging support, but we might end up not having any stack tagging in libc, only in user binaries (used for debugging). > > so stack tagging should work when only some elf modules in a process > > are built with it, which implies that enabling it at dlopen time > > should work otherwise it will not be very useful. > > There is still the small risk of an old object using tagged pointers to > the stack. Since the stack would be shared between such objects, turning > PROT_MTE on would cause issues. Hopefully such problems are minor and > not really a concern for the kernel. > > > do tag checks have overhead if PROT_MTE is not used? i'd expect some > > checks are still done at memory access. (and the tagged address > > syscall abi has to be in use.) > > My understanding from talking to hardware engineers is that there won't > be an overhead if PROT_MTE is not used, no tags being fetched or > checked. But I can't guarantee until we get real silicon. > > > turning sync tag checks on early would enable the most of the > > interesting usecases (only PROT_MTE has to be handled at runtime not > > the prctls. however i don't yet know how userspace will deal with > > compat issues, i.e. it may not be valid to unconditionally turn tag > > checks on early). > > If we change the defaults so that no prctl() is required for the > standard use-case, it would solve most of the common deployment issues: > > 1. Tagged address ABI default on when HWCAP2_MTE is present > 2. Synchronous TCF by default > 3. GCR_EL1.Excl allows all tags except 0 by default > > Any other configuration diverging from the above is considered > specialist deployment and will have to issue the prctl() on a per-thread > basis. > > Compat issues in user-space will be dealt with via environment > variables but pretty much on/off rather than fine-grained tag checking > mode. So for glibc, you'd have only _MTAG=0 or 1 and the only effect is > using PROT_MTE + tagged pointers or no-PROT_MTE + tag 0. enabling mte checks by default would be nice and simple (a libc can support tagging allocators without any change assuming its code is mte safe which is true e.g. for the latest glibc release and for musl libc). the compat issue with this is existing code using pointer top bits which i assume faults when dereferenced with the mte checks enabled. (although this should be very rare since top byte ignore on deref is aarch64 specific.) i see two options: - don't care about top bit compat issues: change the default in the kernel as you described (so checks are enabled and users only need PROT_MTE mapping if they want to use taggging). - care about top bit issues: leave the kernel abi as in the patch set and do the mte setup early in the libc. add elf markings to new binaries that they are mte compatible and libc can use that marking for the mte setup. dlopening incompatible libraries will fail. the issue with this is that we have no idea how to add the marking and the marking prevents mte use with existing binaries (and eg. ldpreload malloc would require an updated libc). for me it's hard to figure out which is the right direction for mte. > > > In the presence of stack tagging, I think any subsequent MTE config > > > change across all threads is unsafe, irrespective of whether it's done > > > by the kernel or user via SIGUSRx. I think the best we can do here is > > > start with more appropriate defaults or enable them based on an ELF note > > > before the application is started. The dynamic loader would not have to > > > do anything extra here. > > > > > > If we ignore stack tagging, the global configuration change may be > > > achievable. I think for the MTE bits, this could be done lazily by the > > > libc (e.g. on malloc()/free() call). The tag checking won't happen > > > before such calls unless we change the kernel defaults. There is still > > > the tagged address ABI enabling, could this be done lazily on syscall by > > > the libc? If not, the kernel could synchronise (force) this on syscall > > > entry from each thread based on some global prctl() bit. > > > > i think the interesting use-cases are all about changing mte settings > > before mte is in use in any way but after there are multiple threads. > > (the async -> sync mode change on tag faults is i think less > > interesting to the gnu linux world.) > > So let's consider async/sync/no-check specialist uses and glibc would > not have to handle them. I don't think async mode is useful on its own > unless you have a way to turn on sync mode at run-time for more precise > error identification (well, hoping that it will happen again). > > > i guess lazy syscall abi switch works, but it is ugly: raw syscall > > usage will be problematic and doing checks before calling into the > > vdso might have unwanted overhead. > > This lazy ABI switch could be handled by the kernel, though I wonder > whether we should just relax it permanently when HWCAP2_MTE is present. yeah i don't immediately see a problem with that. but ideally there would be an escape hatch (a way to opt out from the change). thanks
