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 7FBB0C433EF for ; Thu, 21 Apr 2022 17:24:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03A836B0072; Thu, 21 Apr 2022 13:24:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2B806B0073; Thu, 21 Apr 2022 13:24:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCDA06B0074; Thu, 21 Apr 2022 13:24:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id D01626B0072 for ; Thu, 21 Apr 2022 13:24:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D14E22779F for ; Thu, 21 Apr 2022 17:24:30 +0000 (UTC) X-FDA: 79381560300.07.2ED31AC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 7E20140020 for ; Thu, 21 Apr 2022 17:24:28 +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 dfw.source.kernel.org (Postfix) with ESMTPS id C8DA761D19; Thu, 21 Apr 2022 17:24:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE85AC385A5; Thu, 21 Apr 2022 17:24:24 +0000 (UTC) Date: Thu, 21 Apr 2022 18:24:21 +0100 From: Catalin Marinas To: Kees Cook Cc: Topi Miettinen , 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> <202204210941.4318DE6E8@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202204210941.4318DE6E8@keescook> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7E20140020 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf01.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Stat-Signature: zohm1zqpwyxeo5xhnubqk3sga9rrin3m X-HE-Tag: 1650561868-616698 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 09:42:23AM -0700, Kees Cook wrote: > On Thu, Apr 21, 2022 at 04:35:15PM +0100, 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 "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