public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	systemd-devel@lists.freedesktop.org,
	Kees Cook <keescook@chromium.org>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	toiwoton@gmail.com, libc-alpha@sourceware.org,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Date: Thu, 29 Oct 2020 11:02:22 +0000	[thread overview]
Message-ID: <20201029110220.GC10776@gaia> (raw)
In-Reply-To: <20201027141522.GD27285@arm.com>

On Tue, Oct 27, 2020 at 02:15:22PM +0000, Dave P Martin wrote:
> I also wonder whether we actually care whether the pages are marked
> executable or not here; probably the flags can just be independent.  This
> rather depends on whether the how the architecture treats the BTI (a.k.a
> GP) pagetable bit for non-executable pages.  I have a feeling we already
> allow PROT_BTI && !PROT_EXEC through anyway.
> 
> 
> What about a generic-ish set/clear interface that still works by just
> adding a couple of PROT_ flags:
> 
> 	switch (flags & (PROT_SET | PROT_CLEAR)) {
> 	case PROT_SET: prot |= flags; break;
> 	case PROT_CLEAR: prot &= ~flags; break;
> 	case 0: prot = flags; break;
> 
> 	default:
> 		return -EINVAL;
> 	}
> 
> This can't atomically set some flags while clearing some others, but for
> simple stuff it seems sufficient and shouldn't be too invasive on the
> kernel side.
> 
> We will still have to take the mm lock when doing a SET or CLEAR, but
> not for the non-set/clear case.
> 
> 
> Anyway, libc could now do:
> 
> 	mprotect(addr, len, PROT_SET | PROT_BTI);
> 
> with much the same effect as your PROT_BTI_IF_X.
> 
> 
> JITting or breakpoint setting code that wants to change the permissions
> temporarily, without needing to know whether PROT_BTI is set, say:
> 
> 	mprotect(addr, len, PROT_SET | PROT_WRITE);
> 	*addr = BKPT_INSN;
> 	mprotect(addr, len, PROT_CLEAR | PROT_WRITE);

The problem with this approach is that you can't catch
PROT_EXEC|PROT_WRITE mappings via seccomp. So you'd have to limit it to
some harmless PROT_ flags only. I don't like this limitation, nor the
PROT_BTI_IF_X approach.

The only generic solutions I see are to either use a stateful filter in
systemd or pass the old state to the kernel in a cmpxchg style so that
seccomp can check it (I think you suggest this at some point).

The latter requires a new syscall which is not something we can address
as a quick, back-portable fix here. If systemd cannot be changed to use
a stateful filter for w^x detection, my suggestion is to go for the
kernel setting PROT_BTI on the main executable with glibc changed to
tolerate EPERM on mprotect(). I don't mind adding an AT_FLAGS bit if
needed but I don't think it buys us much.

Once the current problem is fixed, we can look at a better solution
longer term as a new syscall.

-- 
Catalin

  reply	other threads:[~2020-10-29 11:02 UTC|newest]

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 ` [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures 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
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 [this message]
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=20201029110220.GC10776@gaia \
    --to=catalin.marinas@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=broonie@kernel.org \
    --cc=jeremy.linton@arm.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=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
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