From: Kees Cook <keescook@chromium.org>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, hjl.tools@gmail.com,
libc-alpha@sourceware.org, szabolcs.nagy@arm.com,
yu-cheng.yu@intel.com, ebiederm@xmission.com,
linux-arch@vger.kernel.org
Subject: Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter
Date: Wed, 20 Apr 2022 09:51:05 -0700 [thread overview]
Message-ID: <202204200950.C70BFB3@keescook> (raw)
In-Reply-To: <d6c4e1ca-b485-48e5-ede9-d346bd0af599@arm.com>
On Wed, Apr 20, 2022 at 08:39:14AM -0500, Jeremy Linton wrote:
> On 4/20/22 06:57, Mark Brown wrote:
> > On Wed, Apr 20, 2022 at 10:57:30AM +0100, Catalin Marinas wrote:
> > > On Wed, Apr 20, 2022 at 10:36:13AM +0100, Will Deacon wrote:
> >
> > > > Kees, please can you drop this series while Catalin's alternative solution
> > > > is under discussion (his Reviewed-by preceded the other patches)?
> >
> > > > https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@arm.com
> >
> > > > Both series expose new behaviours to userspace and we don't need both.
> >
> > > I agree. Even though the patches have my reviewed-by, I think we should
> > > postpone them until we figure out a better W^X solution that does not
> > > affect BTI (and if we can't, we revisit these patches).
> >
> > Indeed. I had been expecting this to follow the pattern of the previous
> > nine months or so and be mostly ignored for the time being while
> > Catalin's new series goes forward. Now that it's applied it might be
> > worth keeping the first patch still in case someone else needs it but
> > the second patch can probably wait.
> >
> > > Arguably, the two approaches are complementary but the way this series
> > > turned out is for the BTI on main executable to be default off. I have a
> > > worry that the feature won't get used, so we just carry unnecessary code
> > > in the kernel. Jeremy also found this approach less than ideal:
> >
> > > https://lore.kernel.org/r/59fc8a58-5013-606b-f544-8277cda18e50@arm.com
> >
> > I'm not sure there was a fundamental concern with the approach there but
> > rather some pushback on the instance on turning it off by default.
>
> Right, this one seems to have the smallest impact on systemd as it exists
> today. I would have expected the default to be on, because IMHO this set
> corrects what at first glance just looks like a small oversight. I find the
> ABI questions a bit theoretical, given that this should only affect
> environments that don't exist outside of labs/development orgs at this point
> (aka systemd services on HW that implements BTI).
>
>
> The other approach works, and if the systemd folks are on board with it also
> should solve the underlying problem, but it creates a bit of a compatibility
> problem with existing containers/etc that might exist today (although
> running systemd/services in a container is itself a discussion).
>
> So, frankly, I don't see why they aren't complementary. This fixes a bug we
> have today, the other set creates a generic mechanism for the future.
Okay, well, how about I drop this for now, and I'll Ack the ELF loader
changes so this can go through the arm64 tree if there is consensus.
--
Kees Cook
next prev parent reply other threads:[~2022-04-20 16:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 10:51 Mark Brown
2022-04-19 10:51 ` [PATCH v13 1/2] elf: Allow architectures to parse properties on the main executable Mark Brown
2022-04-20 16:51 ` Kees Cook
2022-04-19 10:51 ` [PATCH v13 2/2] arm64: Enable BTI for main executable as well as the interpreter Mark Brown
2022-04-20 5:33 ` [PATCH v13 0/2] arm64: Enable BTI for the " Kees Cook
2022-04-20 9:36 ` Will Deacon
2022-04-20 9:57 ` Catalin Marinas
2022-04-20 11:57 ` Mark Brown
2022-04-20 13:39 ` Jeremy Linton
2022-04-20 16:51 ` Kees Cook [this message]
2022-04-21 9:34 ` Catalin Marinas
2022-04-21 15:52 ` Jeremy Linton
2022-04-21 17:58 ` Mark Brown
2022-04-20 16:48 ` Kees Cook
2022-04-20 16:51 ` Kees Cook
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=202204200950.C70BFB3@keescook \
--to=keescook@chromium.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ebiederm@xmission.com \
--cc=hjl.tools@gmail.com \
--cc=jeremy.linton@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=szabolcs.nagy@arm.com \
--cc=will@kernel.org \
--cc=yu-cheng.yu@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).