The 11/03/2020 23:41, Jeremy Linton wrote: > On 11/3/20 11:34 AM, Mark Brown wrote: > > On Tue, Nov 03, 2020 at 10:25:37AM +0000, Szabolcs Nagy wrote: > > > > > Re-mmap executable segments instead of mprotecting them in > > > case mprotect is seccomp filtered. > > > > > For the kernel mapped main executable we don't have the fd > > > for re-mmap so linux needs to be updated to add BTI. (In the > > > presence of seccomp filters for mprotect(PROT_EXEC) the libc > > > cannot change BTI protection at runtime based on user space > > > policy so it is better if the kernel maps BTI compatible > > > binaries with PROT_BTI by default.) > > > > Given that there were still some ongoing discussions on a more robust > > kernel interface here and there seem to be a few concerns with this > > series should we perhaps just take a step back and disable this seccomp > > filter in systemd on arm64, at least for the time being? That seems > > safer than rolling out things that set ABI quickly, a big part of the > > So, that's a bigger hammer than I think is needed and punishes !BTI > machines. I'm going to suggest that if we need to carry a temp patch its > more like the glibc patch I mentioned in the Fedora defect. That patch > simply logs a message, on the mprotect failures rather than aborting. Its > fairly non-intrusive. > > That leaves seccomp functional, and BTI generally functional except when > seccomp is restricting it. I've also been asked that if a patch like that is > needed, its (temporary?) merged to the glibc trunk, rather than just being > carried by the distro's. note that changing mprotect into mmap in glibc works even if the kernel or systemd decides to do things differently: currently the only wart is that on the main exe we have to use mprotect and silently ignore the failures. (but e.g. some return to libc attacks are reliably prevented since libc.so guaranteed to have PROT_BTI this way.) the patchset is a bit more intrusive than i hoped for, so if we expect to get a new syscall then simply ignoring mprotect failures may be a better temporary solution. (and i still need to do benchmarks to see if the cost of re-mmap is not much more than the cost of mprotect.) changing the seccomp filter in systemd does not help if there are other seccomp filters elsewhere doing the same. i think we will have to avoid using mprotect(PROT_EXEC) or at least ignore the failure. > > reason we went with having the dynamic linker enable PROT_BTI in the > > first place was to give us more flexibility to handle any unforseen > > consequences of enabling BTI that we run into. We are going to have > > similar issues with other features like MTE so we need to make sure that > > whatever we're doing works with them too. > > > > Also updated to Will's current e-mail address - Will, do you have > > thoughts on what we should do here? > >
