Hi,
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.
Thanks,
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?
