Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

Florian Weimer
2020-10-27T14:43:38Z

* 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