(Mark posted another series but I'm replying here to clarify some aspects) On Tue, Jan 18, 2022 at 11:02:55AM +0000, Szabolcs Nagy wrote: > The 01/17/2022 17:54, Catalin Marinas 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. > > Yeah that was my original idea that it should be consistent. > One caveat is that protection flags are normally specified > in the program header, but the BTI marking is in > PT_GNU_PROPERTY which is harder to get to, so glibc does not > try to get it right for the initial mapping either: it has > to re-mmap or mprotect. (In principle we could use read > syscalls to parse the ELF headers and notes before mmap, > but that's more complicated with additional failure modes.) > > i.e. if (2) is fixed then mprotect can be used for library > mapping too which is simpler than re-mmap. I lost track of the userspace fixes here, was glibc changed to attempt a re-mmap of the dynamic libraries instead of mprotect()? It looks like (2) is a simpler fix and (1) could still be added for consistency, it's complementary. > > 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. > > There is some support for text relocations in glibc, but it's not > expected to be common (e.g. it is a bug if a distro binary has it). Thanks for the clarification. -- Catalin
