From: Joey Gouly <joey.gouly@arm.com>
To: "Catalin Marinas" <catalin.marinas@arm.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Lennart Poettering" <lennart@poettering.net>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
Mark Brown <broonie@kernel.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Topi Miettinen <toiwoton@gmail.com>, <linux-mm@kvack.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-abi-devel@lists.sourceforge.net>, <nd@arm.com>,
<joey.gouly@arm.com>, <shuah@kernel.org>
Subject: [PATCH v1 0/2] mm: In-kernel support for memory-deny-write-execute (MDWE)
Date: Wed, 26 Oct 2022 16:04:55 +0100 [thread overview]
Message-ID: <20221026150457.36957-1-joey.gouly@arm.com> (raw)
Hi all,
This is a follow up to the RFC that Catalin posted:
https://lore.kernel.org/linux-arm-kernel/20220413134946.2732468-1-catalin.marinas@arm.com/
The background to this is that systemd has a configuration option called
MemoryDenyWriteExecute [1], implemented as a SECCOMP BPF filter. Its aim
is to prevent a user task from inadvertently creating an executable
mapping that is (or was) writeable. Since such BPF filter is stateless,
it cannot detect mappings that were previously writeable but
subsequently changed to read-only. Therefore the filter simply rejects
any mprotect(PROT_EXEC). The side-effect is that on arm64 with BTI
support (Branch Target Identification), the dynamic loader cannot change
an ELF section from PROT_EXEC to PROT_EXEC|PROT_BTI using mprotect().
For libraries, it can resort to unmapping and re-mapping but for the
main executable it does not have a file descriptor. The original bug
report in the Red Hat bugzilla - [2] - and subsequent glibc workaround
for libraries - [3].
This series adds in-kernel support for this feature as a prctl PR_SET_MDWE,
that is inherited on fork(). The prctl denies PROT_WRITE | PROT_EXEC mappings.
Like the systemd BPF filter it also denies adding PROT_EXEC to mappings.
However unlike the BPF filter it only denies it if the mapping didn't previous
have PROT_EXEC. This allows to PROT_EXEC -> PROT_EXEC | PROT_BTI with mprotect(),
which is a problem with the BPF filter.
Thanks,
Joey
[1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#MemoryDenyWriteExecute=
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1888842
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=26831
Joey Gouly (2):
mm: Implement memory-deny-write-execute as a prctl
kselftest: vm: add tests for memory-deny-write-execute
include/linux/mman.h | 15 ++
include/linux/sched/coredump.h | 6 +-
include/uapi/linux/prctl.h | 6 +
kernel/sys.c | 18 +++
mm/mmap.c | 3 +
mm/mprotect.c | 5 +
tools/testing/selftests/vm/mdwe_test.c | 194 +++++++++++++++++++++++++
7 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/vm/mdwe_test.c
--
2.17.1
next reply other threads:[~2022-10-26 15:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 15:04 Joey Gouly [this message]
2022-10-26 15:04 ` [PATCH v1 1/2] mm: Implement memory-deny-write-execute as a prctl Joey Gouly
2022-10-28 18:51 ` Kees Cook
2022-11-10 11:27 ` Joey Gouly
2022-11-10 12:03 ` Catalin Marinas
2022-11-12 6:11 ` Topi Miettinen
2022-11-15 15:35 ` Catalin Marinas
2022-11-15 19:31 ` Topi Miettinen
2022-10-26 15:04 ` [PATCH v1 2/2] kselftest: vm: add tests for memory-deny-write-execute Joey Gouly
2022-10-28 17:03 ` Mark Brown
2022-11-08 17:33 ` Joey Gouly
2022-11-09 13:33 ` Mark Brown
2022-10-28 17:45 ` Kees Cook
2022-10-28 20:16 ` Kees Cook
2022-11-07 12:23 ` Szabolcs Nagy
2022-10-28 20:19 ` Kees Cook
2022-11-06 19:42 ` [PATCH v1 0/2] mm: In-kernel support for memory-deny-write-execute (MDWE) 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=20221026150457.36957-1-joey.gouly@arm.com \
--to=joey.gouly@arm.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jeremy.linton@arm.com \
--cc=keescook@chromium.org \
--cc=lennart@poettering.net \
--cc=linux-abi-devel@lists.sourceforge.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nd@arm.com \
--cc=shuah@kernel.org \
--cc=szabolcs.nagy@arm.com \
--cc=toiwoton@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zbyszek@in.waw.pl \
/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).