From: Catalin Marinas <catalin.marinas@arm.com> To: Topi Miettinen <toiwoton@gmail.com> Cc: "Kees Cook" <keescook@chromium.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Christoph Hellwig" <hch@infradead.org>, "Lennart Poettering" <lennart@poettering.net>, "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>, "Will Deacon" <will@kernel.org>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Eric Biederman" <ebiederm@xmission.com>, "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, linux-hardening@vger.kernel.org, "Jann Horn" <jannh@google.com>, "Salvatore Mesoraca" <s.mesoraca16@gmail.com>, "Igor Zhbanov" <izh1979@gmail.com> Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Date: Thu, 21 Apr 2022 18:28:58 +0100 [thread overview] Message-ID: <YmGUWq1Ea5koA8mt@arm.com> (raw) In-Reply-To: <400be309-ef3f-4175-594d-7dc45a43dc36@gmail.com> On Thu, Apr 21, 2022 at 07:48:27PM +0300, Topi Miettinen wrote: > On 21.4.2022 18.35, Catalin Marinas wrote: > > 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 we'd want existing installations with MemoryDenyWriteExecute=yes not > start failing when the implementation is changed to in-kernel version. The > implementation could be very simple and not even check existing PROT_ flags > (except for BTI case) to be maximally compatible to BPF version. It would have to check the existing flags otherwise this could have been implemented in the BPF filter. The dynamic loader (or kernel loader) first mmap(PROT_READ|PROT_EXEC) and, if the BTI note is found, it switches it to mprotect(PROT_READ|PROT_EXEC|PROT_BTI). If we allowed this to pass simply because of PROT_BTI, one could create such executable mapping even if it is (or was) writeable. So we can either allow mprotect(PROT_EXEC) if the mapping was never writeable or we allow mprotect(PROT_EXEC) if the mapping is already PROT_EXEC (and the check for W^X was previously done by mmap()). > So I'd leave "was PROT_WRITE" and other checks to more advanced > versions, enabled with a different PR_MDWX_FLAG_. This works for me as well. See my reply to Kees for the use-cases. Thanks. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Topi Miettinen <toiwoton@gmail.com> Cc: "Kees Cook" <keescook@chromium.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Christoph Hellwig" <hch@infradead.org>, "Lennart Poettering" <lennart@poettering.net>, "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>, "Will Deacon" <will@kernel.org>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Eric Biederman" <ebiederm@xmission.com>, "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, linux-hardening@vger.kernel.org, "Jann Horn" <jannh@google.com>, "Salvatore Mesoraca" <s.mesoraca16@gmail.com>, "Igor Zhbanov" <izh1979@gmail.com> Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Date: Thu, 21 Apr 2022 18:28:58 +0100 [thread overview] Message-ID: <YmGUWq1Ea5koA8mt@arm.com> (raw) In-Reply-To: <400be309-ef3f-4175-594d-7dc45a43dc36@gmail.com> On Thu, Apr 21, 2022 at 07:48:27PM +0300, Topi Miettinen wrote: > On 21.4.2022 18.35, Catalin Marinas wrote: > > 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 we'd want existing installations with MemoryDenyWriteExecute=yes not > start failing when the implementation is changed to in-kernel version. The > implementation could be very simple and not even check existing PROT_ flags > (except for BTI case) to be maximally compatible to BPF version. It would have to check the existing flags otherwise this could have been implemented in the BPF filter. The dynamic loader (or kernel loader) first mmap(PROT_READ|PROT_EXEC) and, if the BTI note is found, it switches it to mprotect(PROT_READ|PROT_EXEC|PROT_BTI). If we allowed this to pass simply because of PROT_BTI, one could create such executable mapping even if it is (or was) writeable. So we can either allow mprotect(PROT_EXEC) if the mapping was never writeable or we allow mprotect(PROT_EXEC) if the mapping is already PROT_EXEC (and the check for W^X was previously done by mmap()). > So I'd leave "was PROT_WRITE" and other checks to more advanced > versions, enabled with a different PR_MDWX_FLAG_. This works for me as well. See my reply to Kees for the use-cases. Thanks. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-21 17:29 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-13 13:49 [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 1/4] mm: Track previously writeable vma permission Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 2/4] mm, personality: Implement memory-deny-write-execute as a personality flag Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-21 17:37 ` David Hildenbrand 2022-04-21 17:37 ` David Hildenbrand 2022-04-22 10:28 ` Catalin Marinas 2022-04-22 10:28 ` Catalin Marinas 2022-04-22 11:04 ` David Hildenbrand 2022-04-22 11:04 ` David Hildenbrand 2022-04-22 13:12 ` Catalin Marinas 2022-04-22 13:12 ` Catalin Marinas 2022-04-22 17:41 ` David Hildenbrand 2022-04-22 17:41 ` David Hildenbrand 2022-04-13 13:49 ` [PATCH RFC 3/4] fs/binfmt_elf: Tell user-space about the DENY_WRITE_EXEC " Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 13:49 ` [PATCH RFC 4/4] arm64: Select ARCH_ENABLE_DENY_WRITE_EXEC Catalin Marinas 2022-04-13 13:49 ` Catalin Marinas 2022-04-13 18:39 ` [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Topi Miettinen 2022-04-13 18:39 ` Topi Miettinen 2022-04-14 13:49 ` Catalin Marinas 2022-04-14 13:49 ` Catalin Marinas 2022-04-14 18:52 ` Kees Cook 2022-04-14 18:52 ` Kees Cook 2022-04-15 20:01 ` Topi Miettinen 2022-04-15 20:01 ` Topi Miettinen 2022-04-20 13:01 ` Catalin Marinas 2022-04-20 13:01 ` Catalin Marinas 2022-04-20 17:44 ` Kees Cook 2022-04-20 17:44 ` Kees Cook 2022-04-20 19:34 ` Topi Miettinen 2022-04-20 19:34 ` Topi Miettinen 2022-04-20 23:21 ` Kees Cook 2022-04-20 23:21 ` Kees Cook 2022-04-21 15:35 ` Catalin Marinas 2022-04-21 15:35 ` Catalin Marinas 2022-04-21 16:42 ` Kees Cook 2022-04-21 16:42 ` Kees Cook 2022-04-21 17:24 ` Catalin Marinas 2022-04-21 17:24 ` Catalin Marinas 2022-04-21 17:41 ` Kees Cook 2022-04-21 17:41 ` Kees Cook 2022-04-21 18:33 ` Catalin Marinas 2022-04-21 18:33 ` Catalin Marinas 2022-04-21 16:48 ` Topi Miettinen 2022-04-21 16:48 ` Topi Miettinen 2022-04-21 17:28 ` Catalin Marinas [this message] 2022-04-21 17:28 ` Catalin Marinas
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=YmGUWq1Ea5koA8mt@arm.com \ --to=catalin.marinas@arm.com \ --cc=akpm@linux-foundation.org \ --cc=broonie@kernel.org \ --cc=ebiederm@xmission.com \ --cc=hch@infradead.org \ --cc=izh1979@gmail.com \ --cc=jannh@google.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-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=s.mesoraca16@gmail.com \ --cc=szabolcs.nagy@arm.com \ --cc=toiwoton@gmail.com \ --cc=viro@zeniv.linux.org.uk \ --cc=will@kernel.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.