From: Topi Miettinen <toiwoton@gmail.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Kees Cook <keescook@chromium.org>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
libc-alpha@sourceware.org, systemd-devel@lists.freedesktop.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
Dave Martin <dave.martin@arm.com>,
Will Deacon <will.deacon@arm.com>,
Salvatore Mesoraca <s.mesoraca16@gmail.com>,
kernel-hardening@lists.openwall.com,
linux-hardening@vger.kernel.org
Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Date: Sat, 24 Oct 2020 14:01:30 +0300 [thread overview]
Message-ID: <cf655c11-d854-281a-17ae-262ddf0aaa08@gmail.com> (raw)
In-Reply-To: <20201023090232.GA25736@gaia>
On 23.10.2020 12.02, Catalin Marinas wrote:
> On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
>> Regardless, it makes sense to me to have the kernel load the executable
>> itself with BTI enabled by default. I prefer gaining Catalin's suggested
>> patch[2]. :)
> [...]
>> [2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/
>
> I think I first heard the idea at Mark R ;).
>
> It still needs glibc changes to avoid the mprotect(), or at least ignore
> the error. Since this is an ABI change and we don't know which kernels
> would have it backported, maybe better to still issue the mprotect() but
> ignore the failure.
What about kernel adding an auxiliary vector as a flag to indicate that
BTI is supported and recommended by the kernel? Then dynamic loader
could use that to detect that a) the main executable is BTI protected
and there's no need to mprotect() it and b) PROT_BTI flag should be
added to all PROT_EXEC pages.
In absence of the vector, the dynamic loader might choose to skip doing
PROT_BTI at all (since the main executable isn't protected anyway
either, or maybe even the kernel is up-to-date but it knows that it's
not recommended for some reason, or maybe the kernel is so ancient that
it doesn't know about BTI). Optionally it could still read the flag from
ELF later (for compatibility with old kernels) and then do the
mprotect() dance, which may trip seccomp filters, possibly fatally.
-Topi
next prev parent reply other threads:[~2020-10-24 11:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com>
[not found] ` <20201022075447.GO3819@arm.com>
[not found] ` <78464155-f459-773f-d0ee-c5bdbeb39e5d@gmail.com>
2020-10-22 20:02 ` BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Kees Cook
2020-10-22 22:24 ` Topi Miettinen
2020-10-23 17:52 ` Salvatore Mesoraca
2020-10-24 11:34 ` Topi Miettinen
2020-10-24 14:12 ` Salvatore Mesoraca
2020-10-25 13:42 ` Jordan Glover
2020-10-23 9:02 ` Catalin Marinas
2020-10-24 11:01 ` Topi Miettinen [this message]
2020-10-26 14:52 ` Catalin Marinas
2020-10-26 15:56 ` Dave Martin
2020-10-26 16:51 ` Mark Brown
2020-10-26 16:31 ` Topi Miettinen
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=cf655c11-d854-281a-17ae-262ddf0aaa08@gmail.com \
--to=toiwoton@gmail.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.martin@arm.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=s.mesoraca16@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=szabolcs.nagy@arm.com \
--cc=will.deacon@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).