Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Lennart Poettering <mzxreary@0pointer.de>
Cc: Florian Weimer <fweimer@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	systemd-devel@lists.freedesktop.org,
	Kees Cook <keescook@chromium.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Topi Miettinen <toiwoton@gmail.com>,
	libc-alpha@sourceware.org, Dave Martin <dave.martin@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Date: Thu, 22 Oct 2020 10:31:05 +0100
Message-ID: <20201022093104.GB1229@gaia> (raw)
In-Reply-To: <20201022083823.GA324825@gardel-login>

On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
> On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.nagy@arm.com) wrote:
> > > > The dynamic loader has to process the LOAD segments to get to the ELF
> > > > note that says to enable BTI.  Maybe we could do a first pass and load
> > > > only the segments that cover notes.  But that requires lots of changes
> > > > to generic code in the loader.
> > >
> > > What if the loader always enabled BTI for PROT_EXEC pages, but then when
> > > discovering that this was a mistake, mprotect() the pages without BTI? Then
> > > both BTI and MDWX would work and the penalty of not getting MDWX would fall
> > > to non-BTI programs. What's the expected proportion of BTI enabled code vs.
> > > disabled in the future, is it perhaps expected that a distro would enable
> > > the flag globally so eventually only a few legacy programs might be
> > > unprotected?
> >
> > i thought mprotect(PROT_EXEC) would get filtered
> > with or without bti, is that not the case?
> 
> We can adjust the filter in systemd to match any combination of
> flags to allow and to deny.

Yes but Szabolcs' point to Topi was that if we can adjust the filters to
allow mprotect(PROT_EXEC), why not allow mprotect(PROT_EXEC|PROT_BTI)
instead? Anyway, I see the MDWX and BTI as complementary policies so
ideally we shouldn't have to choose between one or the other. If we
allow mprotect(PROT_EXEC), that would override MDWX and also disable
BTI.

IIUC, the problem is with the main executable which is mapped by the
kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but
does not have the original file descriptor to be able to remap. Its only
choice is mprotect() and this fails because of the MDWX policy.

Not sure whether the kernel has the right information but could it map
the main executable with PROT_BTI if the corresponding PT_GNU_PROPERTY
is found? The current ABI states it only sets PROT_BTI for the
interpreter who'd be responsible for setting the PROT_BTI on the main
executable. I can't tell whether it would break anything but it's worth
a try:

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 4784011cecac..0a08fb9133e8 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -730,14 +730,6 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void)
 int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state,
 			 bool has_interp, bool is_interp)
 {
-	/*
-	 * For dynamically linked executables the interpreter is
-	 * responsible for setting PROT_BTI on everything except
-	 * itself.
-	 */
-	if (is_interp != has_interp)
-		return prot;
-
 	if (!(state->flags & ARM64_ELF_BTI))
 		return prot;
 

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com>
2020-10-22  7:18 ` Lennart Poettering
2020-10-22  7:54   ` Florian Weimer
2020-10-22  8:17     ` Topi Miettinen
2020-10-22  8:25       ` Florian Weimer
2020-10-22  8:29       ` Szabolcs Nagy
2020-10-22  8:38         ` Lennart Poettering
2020-10-22  9:31           ` Catalin Marinas [this message]
2020-10-22 10:12             ` Topi Miettinen
2020-10-22 10:27               ` Florian Weimer
2020-10-23  6:13             ` Szabolcs Nagy
2020-10-23  9:04               ` Catalin Marinas
2020-10-22 10:03         ` Topi Miettinen
2020-10-22  8:05   ` Szabolcs Nagy
2020-10-22  8:31     ` Lennart Poettering
     [not found] ` <20201022075447.GO3819@arm.com>
2020-10-22 10:39   ` Topi Miettinen
2020-10-22 20:02     ` 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
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
2020-10-26 16:24 ` Dave Martin
2020-10-26 16:39   ` Topi Miettinen
2020-10-26 16:45   ` Florian Weimer
2020-10-27 14:22     ` Dave Martin
2020-10-27 14:41       ` Florian Weimer
2020-10-26 16:57   ` Szabolcs Nagy
2020-10-26 17:52     ` Dave Martin
2020-10-26 22:39       ` Jeremy Linton
2020-10-27 14:15         ` Dave Martin
2020-10-29 11:02           ` Catalin Marinas
2020-11-04 12:18             ` Dave Martin

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=20201022093104.GB1229@gaia \
    --to=catalin.marinas@arm.com \
    --cc=broonie@kernel.org \
    --cc=dave.martin@arm.com \
    --cc=fweimer@redhat.com \
    --cc=keescook@chromium.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mzxreary@0pointer.de \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=szabolcs.nagy@arm.com \
    --cc=toiwoton@gmail.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

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git