On Mon, Jan 17, 2022 at 10:17 AM Adhemerval Zanella via Libc-alpha <libc-alpha@xxxxxxxxxxxxxx> wrote: > > > > On 17/01/2022 14:54, Catalin Marinas via Libc-alpha wrote: > > On Fri, Jan 07, 2022 at 12:01:17PM +0000, Catalin Marinas wrote: > >> I think we can look at this from two angles: > >> > >> 1. Ignoring MDWE, should whoever does the original mmap() also honour > >> PROT_BTI? We do this for static binaries but, for consistency, should > >> we extend it to dynamic executable? > >> > >> 2. A 'simple' fix to allow MDWE together with BTI. > > > > Thinking about it, (1) is not that different from the kernel setting > > PROT_EXEC on the main executable when the dynamic loader could've done > > it as well. There is a case for making this more consistent: whoever > > does the mmap() should use the full attributes. > > > > Question for the toolchain people: would the compiler ever generate > > relocations in the main executable that the linker needs to resolve via > > an mprotect(READ|WRITE) followed by mprotect(READ|EXEC)? If yes, we'd > > better go for a proper MDWE implementation in the kernel. > > > > Yes, text relocations. However these are deprecated (some libcs even do > not support it) and have a lot of drawbacks. We are taking a different approach for CET enabling. CET will be changed to be enabled from user space: https://gitlab.com/x86-glibc/glibc/-/tree/users/hjl/cet/enable and the CET kernel no longer enables CET automatically: https://github.com/hjl-tools/linux/tree/hjl/cet%2F5.16.0-v4 -- H.J.
