[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1pl9brd.fsf@oldenburg2.str.redhat.com>
Date: Mon, 26 Oct 2020 17:45:42 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Dave Martin via Libc-alpha <libc-alpha@...rceware.org>
Cc: Jeremy Linton <jeremy.linton@....com>,
Dave Martin <Dave.Martin@....com>,
Mark Rutland <mark.rutland@....com>,
systemd-devel@...ts.freedesktop.org,
Kees Cook <keescook@...omium.org>,
Catalin Marinas <Catalin.Marinas@....com>,
Will Deacon <will.deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Brown <broonie@...nel.org>, toiwoton@...il.com,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: BTI interaction between seccomp filters in systemd and glibc
mprotect calls, causing service failures
* 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
--
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
Powered by blists - more mailing lists