[systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Florian Weimer
fweimer at redhat.com
Tue Oct 27 14:41:16 UTC 2020
* Dave Martin via Libc-alpha:
> On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
>> * Dave Martin via Libc-alpha:
>>
>> > Would it now help to add something like:
>> >
>> > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
>> > {
>> > int ret = -EINVAL;
>> > mmap_write_lock(current->mm);
>> > if (all vmas in [addr .. addr + len) have
>> > their mprotect flags set to old_flags) {
>> >
>> > ret = mprotect(addr, len, new_flags);
>> > }
>> >
>> > mmap_write_unlock(current->mm);
>> > return ret;
>> > }
>>
>> I suggested something similar as well. Ideally, the interface would
>> subsume pkey_mprotect, though, and have a separate flags argument from
>> the protection flags. But then we run into argument list length limits.
>>
>> Thanks,
>> Florian
>
> I suppose. Assuming that a syscall filter can inspect memory, we might
> be able to bundle arguments into a struct if necessary.
But that leads to a discussion about batch mmap/mprotect/munmap, and
that's again incompatible with seccomp (it would need a checking loop).
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
More information about the systemd-devel
mailing list