[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201104085704.GB24704@arm.com>
Date: Wed, 4 Nov 2020 08:57:05 +0000
From: Szabolcs Nagy <szabolcs.nagy@....com>
To: Jeremy Linton <jeremy.linton@....com>
Cc: Mark Brown <broonie@...nel.org>, libc-alpha@...rceware.org,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>, Will Deacon <will@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
Kees Cook <keescook@...omium.org>,
Salvatore Mesoraca <s.mesoraca16@...il.com>,
Lennart Poettering <mzxreary@...inter.de>,
Topi Miettinen <toiwoton@...il.com>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
kernel-hardening@...ts.openwall.com,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ
#26831]
The 11/03/2020 23:41, Jeremy Linton wrote:
> On 11/3/20 11:34 AM, Mark Brown wrote:
> > On Tue, Nov 03, 2020 at 10:25:37AM +0000, Szabolcs Nagy wrote:
> >
> > > Re-mmap executable segments instead of mprotecting them in
> > > case mprotect is seccomp filtered.
> >
> > > For the kernel mapped main executable we don't have the fd
> > > for re-mmap so linux needs to be updated to add BTI. (In the
> > > presence of seccomp filters for mprotect(PROT_EXEC) the libc
> > > cannot change BTI protection at runtime based on user space
> > > policy so it is better if the kernel maps BTI compatible
> > > binaries with PROT_BTI by default.)
> >
> > Given that there were still some ongoing discussions on a more robust
> > kernel interface here and there seem to be a few concerns with this
> > series should we perhaps just take a step back and disable this seccomp
> > filter in systemd on arm64, at least for the time being? That seems
> > safer than rolling out things that set ABI quickly, a big part of the
>
> So, that's a bigger hammer than I think is needed and punishes !BTI
> machines. I'm going to suggest that if we need to carry a temp patch its
> more like the glibc patch I mentioned in the Fedora defect. That patch
> simply logs a message, on the mprotect failures rather than aborting. Its
> fairly non-intrusive.
>
> That leaves seccomp functional, and BTI generally functional except when
> seccomp is restricting it. I've also been asked that if a patch like that is
> needed, its (temporary?) merged to the glibc trunk, rather than just being
> carried by the distro's.
note that changing mprotect into mmap in glibc works
even if the kernel or systemd decides to do things
differently: currently the only wart is that on the
main exe we have to use mprotect and silently ignore
the failures. (but e.g. some return to libc attacks
are reliably prevented since libc.so guaranteed to
have PROT_BTI this way.)
the patchset is a bit more intrusive than i hoped
for, so if we expect to get a new syscall then
simply ignoring mprotect failures may be a better
temporary solution. (and i still need to do
benchmarks to see if the cost of re-mmap is not
much more than the cost of mprotect.)
changing the seccomp filter in systemd does not
help if there are other seccomp filters elsewhere
doing the same. i think we will have to avoid using
mprotect(PROT_EXEC) or at least ignore the failure.
> > reason we went with having the dynamic linker enable PROT_BTI in the
> > first place was to give us more flexibility to handle any unforseen
> > consequences of enabling BTI that we run into. We are going to have
> > similar issues with other features like MTE so we need to make sure that
> > whatever we're doing works with them too.
> >
> > Also updated to Will's current e-mail address - Will, do you have
> > thoughts on what we should do here?
> >
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
