From: Mark Brown <broonie@kernel.org>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
libc-alpha@sourceware.org,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>,
Florian Weimer <fweimer@redhat.com>,
Kees Cook <keescook@chromium.org>,
Salvatore Mesoraca <s.mesoraca16@gmail.com>,
Lennart Poettering <mzxreary@0pointer.de>,
Topi Miettinen <toiwoton@gmail.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kernel-hardening@lists.openwall.com,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]
Date: Wed, 4 Nov 2020 10:50:58 +0000 [thread overview]
Message-ID: <20201104105058.GA4812@sirena.org.uk> (raw)
In-Reply-To: <8c99cc8e-41af-d066-b786-53ac13c2af8a@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
On Tue, Nov 03, 2020 at 11:41:42PM -0600, Jeremy Linton wrote:
> On 11/3/20 11:34 AM, Mark Brown wrote:
> > 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.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-11-04 10:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 10:25 [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831] Szabolcs Nagy
2020-11-03 10:25 ` [PATCH 1/4] elf: Pass the fd to note processing " Szabolcs Nagy
2020-11-03 10:26 ` [PATCH 2/4] elf: Move note processing after l_phdr is updated " Szabolcs Nagy
2020-11-03 10:38 ` Florian Weimer
2020-11-03 12:36 ` H.J. Lu
2020-11-03 15:04 ` Szabolcs Nagy
2020-11-03 15:27 ` H.J. Lu
2020-11-03 10:26 ` [PATCH 3/4] aarch64: Use mmap to add PROT_BTI instead of mprotect " Szabolcs Nagy
2020-11-03 10:34 ` Florian Weimer
2020-11-03 10:26 ` [PATCH 4/4] aarch64: Remove the bti link_map field " Szabolcs Nagy
2020-11-03 17:34 ` [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) " Mark Brown
2020-11-04 5:41 ` Jeremy Linton
2020-11-04 8:57 ` Szabolcs Nagy
2020-11-04 14:41 ` Catalin Marinas
2020-11-04 14:45 ` Florian Weimer
2020-11-04 10:50 ` Mark Brown [this message]
2020-11-04 18:47 ` Jeremy Linton
2020-11-04 18:53 ` Mark Brown
2020-11-04 9:02 ` Topi Miettinen
2020-11-04 9:20 ` Will Deacon
2020-11-04 9:29 ` Florian Weimer
2020-11-04 9:55 ` Topi Miettinen
2020-11-04 14:35 ` Catalin Marinas
2020-11-04 15:19 ` Topi Miettinen
2020-11-04 16:08 ` Szabolcs Nagy
2020-11-04 15:20 ` Mark Rutland
2020-11-04 18:59 ` Jeremy Linton
2020-11-05 11:31 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201104105058.GA4812@sirena.org.uk \
--to=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=fweimer@redhat.com \
--cc=jeremy.linton@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mzxreary@0pointer.de \
--cc=s.mesoraca16@gmail.com \
--cc=szabolcs.nagy@arm.com \
--cc=toiwoton@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox