[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201104185342.GC4812@sirena.org.uk>
Date: Wed, 4 Nov 2020 18:53:42 +0000
From: Mark Brown <broonie@...nel.org>
To: Jeremy Linton <jeremy.linton@....com>
Cc: Szabolcs Nagy <szabolcs.nagy@....com>, 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]
On Wed, Nov 04, 2020 at 12:47:09PM -0600, Jeremy Linton wrote:
> On 11/4/20 4:50 AM, Mark Brown wrote:
> > The effect on pre-BTI hardware is an issue, another option would be for
> > systemd to disable this seccomp usage but only after checking for BTI
> > support in the system rather than just doing so purely based on the
> > architecture.
> That works, but your also losing seccomp in the case where the machine is
> BTI capable, but the service isn't. So it should really be checking the elf
> notes, but at that point you might just as well patch glibc.
True, I guess I was assuming that a BTI rebuild is done at the distro
level but of course even if that's the case a system could have third
party binaries so you can't just assume that the world is BTI.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
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.
