Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE)
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2022-04-21 17:24:43
Also in:
linux-hardening, linux-mm, lkml
On Thu, Apr 21, 2022 at 09:42:23AM -0700, Kees Cook wrote:
On Thu, Apr 21, 2022 at 04:35:15PM +0100, Catalin Marinas wrote:quoted
Do we want the "was PROT_WRITE" or we just reject mprotect(PROT_EXEC) if the vma is not already PROT_EXEC? The latter is closer to the current systemd approach. The former allows an mprotect(PROT_EXEC) if the mapping was PROT_READ only for example. I'd drop the "was PROT_WRITE" for now if the aim is a drop-in replacement for BPF MDWE.I think "was PROT_WRITE" is an important part of the defense that couldn't be done with a simple seccomp filter (which is why the filter ended up being a problem in the first place).
I would say "was PROT_WRITE" is slightly more relaxed than "is not already PROT_EXEC". The seccomp filter can't do "is not already PROT_EXEC" either since it only checks the mprotect() arguments, not the current vma flags. So we have (with sub-cases): 1. Current BPF filter: a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails b) mmap(PROT_READ|PROT_EXEC); mprotect(PROT_READ|PROT_EXEC|PROT_BTI); // fails 2. "is not already PROT_EXEC": a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails b) mmap(PROT_READ|PROT_EXEC); mmap(PROT_READ|PROT_EXEC|PROT_BTI); // passes c) mmap(PROT_READ); mprotect(PROT_READ|PROT_EXEC); // fails 3. "is or was not PROT_WRITE": a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails b) mmap(PROT_READ|PROT_EXEC); mmap(PROT_READ|PROT_EXEC|PROT_BTI); // passes c) mmap(PROT_READ); mprotect(PROT_READ|PROT_EXEC); // passes d) mmap(PROT_READ|PROT_WRITE); mprotect(PROT_READ); mprotect(PROT_READ|PROT_EXEC); // fails (was write) The current seccomp filter is the strictest. If we go for (2), it allows PROT_BTI as in 2.b but prevents 2.c (as would the current seccomp filter). (3) relaxes 2.c as in 3.c while still preventing 3.d. Both (1) and (2) prevent 3.d by simply rejecting mprotect(PROT_EXEC). If we don't care about 3.c, we might as well go for (2). I don't mind, already went for (3) in this series. I think either of them would not be a regression on MDWE, unless there is some test that attempts 3.c and expects it to fail. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel