From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16290C433F5 for ; Thu, 21 Apr 2022 17:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A475C6B0072; Thu, 21 Apr 2022 13:29:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D0D06B0073; Thu, 21 Apr 2022 13:29:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 872206B0074; Thu, 21 Apr 2022 13:29:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 762646B0072 for ; Thu, 21 Apr 2022 13:29:09 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4FD0B23383 for ; Thu, 21 Apr 2022 17:29:09 +0000 (UTC) X-FDA: 79381572018.06.7B71F7C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf05.hostedemail.com (Postfix) with ESMTP id 21EEB10002C for ; Thu, 21 Apr 2022 17:29:05 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C60D5B82874; Thu, 21 Apr 2022 17:29:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1ABA7C385A5; Thu, 21 Apr 2022 17:29:01 +0000 (UTC) Date: Thu, 21 Apr 2022 18:28:58 +0100 From: Catalin Marinas To: Topi Miettinen Cc: Kees Cook , Andrew Morton , Christoph Hellwig , Lennart Poettering , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Will Deacon , Alexander Viro , Eric Biederman , Szabolcs Nagy , Mark Brown , Jeremy Linton , 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 , Salvatore Mesoraca , Igor Zhbanov Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Message-ID: References: <20220413134946.2732468-1-catalin.marinas@arm.com> <202204141028.0482B08@keescook> <202204201610.093C9D5FE8@keescook> <400be309-ef3f-4175-594d-7dc45a43dc36@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <400be309-ef3f-4175-594d-7dc45a43dc36@gmail.com> X-Stat-Signature: 1jgkk4kkgknzg65ensb337t8j1ezk6cr X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf05.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 21EEB10002C X-HE-Tag: 1650562145-204794 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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