Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.