public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	"H . J . Lu" <hjl.tools@gmail.com>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	libc-alpha@sourceware.org
Subject: Re: [PATCH v8 0/4] arm64: Enable BTI for the executable as well as the interpreter
Date: Tue, 22 Feb 2022 14:15:14 +0000	[thread overview]
Message-ID: <YhTv8p5JVPjqW8nE@sirena.org.uk> (raw)
In-Reply-To: <Ygz9YX3jBY0MpepU@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

On Wed, Feb 16, 2022 at 01:34:25PM +0000, Catalin Marinas wrote:
> On Tue, Feb 15, 2022 at 06:34:56PM +0000, Will Deacon wrote:

> > This appears to be a user-visible change which cannot be detected or
> > disabled from userspace. If there is code out there which does not work
> > when BTI is enabled, won't that now explode when the kernel enables it?
> > How are we supposed to handle such a regression?

> If this ever happens, the only workaround is to disable BTI on the
> kernel command line. If we need a knob closer to user, we could add a
> sysctl option (as we did for the tagged address ABI, though I doubt
> people are even aware that exists). The dynamic loader doesn't do
> anything smart when deciding to map objects with PROT_BTI (like env
> variables), it simply relies on the ELF information.

The dynamic loader is the place where I'd expect to do any
per-executable workarounds, but currently that's not actually
implemented anywhere.  Someone could also make a tool to strip BTI
annotations from executables.

> I think the only difference would be with a BTI-unware dynamic loader
> (e.g. older distro). Here the main executable, if compiled with BTI,
> would be mapped as executable while the rest of the libraries are
> non-BTI. The interworking should be fine but we can't test everything
> since such BTI binaries would not normally be part of the distro.

> If there are dodgy libraries out there that do tricks and branch into
> the middle of a function in the main executable, they will fail with
> this series but also fail if MDWE is disabled and the dynamic linker is
> BTI-aware. So this hardly counts as a use-case.

I'm not aware of any issues we've run into which are due to interworking
between binaries rather than within a binary due to either miscompilation
or doing something in hand coded assembler that needs updating for BTI.
It doesn't mean it can't happen but it's hard to see what people might
be doing.

> For consistency, I think whoever does the initial mapping should also
> set the correct attributes as we do for static binaries. If you think
> another knob is needed other than the cmdline, I'm fine with it.

Might also be worth pointing out that we already map the vDSO with BTI
enabled if it's built with BTI.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2022-02-22 14:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24 15:07 Mark Brown
2022-01-24 15:07 ` [PATCH v8 1/4] elf: Allow architectures to parse properties on the main executable Mark Brown
2022-02-04 13:00   ` Catalin Marinas
2022-01-24 15:07 ` [PATCH v8 2/4] arm64: Enable BTI for main executable as well as the interpreter Mark Brown
2022-02-04 13:11   ` Catalin Marinas
2022-01-24 15:07 ` [PATCH v8 3/4] elf: Remove has_interp property from arch_adjust_elf_prot() Mark Brown
2022-02-04 14:53   ` Catalin Marinas
2022-01-24 15:07 ` [PATCH v8 4/4] elf: Remove has_interp property from arch_parse_elf_property() Mark Brown
2022-02-04 14:54   ` Catalin Marinas
2022-02-15 18:34 ` [PATCH v8 0/4] arm64: Enable BTI for the executable as well as the interpreter Will Deacon
2022-02-16 13:34   ` Catalin Marinas
2022-02-16 16:49     ` Szabolcs Nagy
2022-02-16 17:01       ` Mark Brown
2022-02-17  8:17         ` Szabolcs Nagy
2022-02-22 14:15     ` Mark Brown [this message]
2022-02-25 13:53     ` Will Deacon
2022-02-25 15:11       ` Mark Brown
2022-02-25 15:54         ` Will Deacon

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=YhTv8p5JVPjqW8nE@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.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).