[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201027142218.GE27285@arm.com>
Date: Tue, 27 Oct 2020 14:22:19 +0000
From: Dave Martin <Dave.Martin@....com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Dave Martin via Libc-alpha <libc-alpha@...rceware.org>,
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>,
Jeremy Linton <jeremy.linton@....com>,
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
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.
[...]
Cheers
---Dave
Powered by blists - more mailing lists