From: Topi Miettinen <toiwoton@gmail.com>
To: "Joey Gouly" <joey.gouly@arm.com>,
"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>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-abi-devel@lists.sourceforge.net, nd@arm.com,
shuah@kernel.org
Subject: Re: [PATCH v1 0/2] mm: In-kernel support for memory-deny-write-execute (MDWE)
Date: Sun, 6 Nov 2022 21:42:30 +0200 [thread overview]
Message-ID: <25bd279e-f429-3772-bbea-ad56a7a810e5@gmail.com> (raw)
In-Reply-To: <20221026150457.36957-1-joey.gouly@arm.com>
On 26.10.2022 18.04, Joey Gouly wrote:
> 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.
Draft PR for systemd: https://github.com/systemd/systemd/pull/25276
-Topi
>
> 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
>
prev parent reply other threads:[~2022-11-06 19:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 15:04 [PATCH v1 0/2] mm: In-kernel support for memory-deny-write-execute (MDWE) Joey Gouly
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 ` Topi Miettinen [this message]
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=25bd279e-f429-3772-bbea-ad56a7a810e5@gmail.com \
--to=toiwoton@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jeremy.linton@arm.com \
--cc=joey.gouly@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=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).