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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A583C433FE for ; Thu, 21 Apr 2022 17:24:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232694AbiDUR10 (ORCPT ); Thu, 21 Apr 2022 13:27:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1390577AbiDUR1U (ORCPT ); Thu, 21 Apr 2022 13:27:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 411C32B251; Thu, 21 Apr 2022 10:24:29 -0700 (PDT) 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 C90BA61DFA; 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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