Messages in this thread | | | From | Florian Weimer <> | Subject | Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures | Date | Thu, 22 Oct 2020 12:27:00 +0200 |
| |
* Topi Miettinen:
> Allowing mprotect(PROT_EXEC|PROT_BTI) would mean that all you need to > circumvent MDWX is to add PROT_BTI flag. I'd suggest getting the flags > right at mmap() time or failing that, reverting the PROT_BTI for > legacy programs later. > > Could the kernel tell the loader of the BTI situation with auxiliary > vectors? Then it would be easy for the loader to always use the best > mmap() flags without ever needing to mprotect().
I think what we want is a mprotect2 call with a flags argument (separate from protection flags) that tells the kernel that the request *removes* protection flags and should fail otherwise. seccomp could easily filter that then.
But like the other proposals, the migration story isn't great. You would need kernel and seccomp/systemd etc. updates before glibc starts working, even if glibc has a fallback from mprotect2 to mprotect (because the latter would be blocked).
Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
| |