* Lennart Poettering: > On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.linton@xxxxxxx) wrote: > >> Hi, >> >> There is a problem with glibc+systemd on BTI enabled systems. Systemd >> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny >> PROT_EXEC changes. Glibc enables BTI only on segments which are marked as >> being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is >> caught by the seccomp filter, resulting in service failures. >> >> So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. >> This is obviously not desirable. >> >> Various changes have been suggested, replacing the mprotect with mmap calls >> having PROT_BTI set on the original mapping, re-mmapping the segments, >> implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, >> and various modification to seccomp to allow particular mprotect cases to >> bypass the filters. In each case there seems to be an undesirable attribute >> to the solution. >> >> So, whats the best solution? > > Did you see Topi's comments on the systemd issue? > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > I think I agree with this: it's a bit weird to alter the bits after > the fact. Can't glibc set up everything right from the begining? That > would keep both concepts working. The dynamic loader has to process the LOAD segments to get to the ELF note that says to enable BTI. Maybe we could do a first pass and load only the segments that cover notes. But that requires lots of changes to generic code in the loader. 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
- From: Florian Weimer <fweimer@xxxxxxxxxx>
- Date: Thu, 22 Oct 2020 09:54:52 +0200
- Cc: Mark Rutland <mark.rutland@xxxxxxx>, systemd-devel@xxxxxxxxxxxxxxxxxxxxx, Kees Cook <keescook@xxxxxxxxxxxx>, Catalin Marinas <Catalin.Marinas@xxxxxxx>, Will Deacon <will.deacon@xxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Mark Brown <broonie@xxxxxxxxxx>, libc-alpha@xxxxxxxxxxxxxx, Dave Martin <dave.martin@xxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <20201022071812.GA324655@gardel-login> (Lennart Poettering's message of "Thu, 22 Oct 2020 09:18:12 +0200")
- References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022071812.GA324655@gardel-login>
- User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
- Follow-Ups:
- References:
- Prev by Date: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
- Next by Date: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
- Previous by thread: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
- Next by thread: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
- Index(es):
 |