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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AF009C433F5 for ; Fri, 15 Apr 2022 20:02:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=e+qs1LAD4h5wFF1Uh/m9SIlJ8Q2/NDPQD1g4eQVSiig=; b=g/TuK/dV34Otva hd8xjp4y36zN8qbJ+5ChKRjnAiLgbEAybuE76eJXomCpmFt7CIlRekBEStNNb8LPY8OYmzV/OjEjH 7ohf1uQMjnZQrTU8riedinPKySGDxDokvfeUI2XaMWtO5Hxfzn2CjBmBWH1FJpmwy62a8wlWzjiNF jRVQPyUE/aIwHroFjDry1bS41EOaZC530T6Td5lxZ/VTo5v8HUD6E1A7nOTTnZOIEHMk7iNF0XVgy VG/qXZIj+yJYBRes2XeZUlLmeIM9hINDrCmeoqBIrZMoxCpCPy4qKwMcV0cr0yfTZ1HM4PtjP3ELs 3UCrDduhAgNaTDNrqaJw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfS7y-00BDAL-FR; Fri, 15 Apr 2022 20:01:10 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfS7u-00BD9F-Tc for linux-arm-kernel@lists.infradead.org; Fri, 15 Apr 2022 20:01:08 +0000 Received: by mail-lj1-x236.google.com with SMTP id n17so5581670ljc.11 for ; Fri, 15 Apr 2022 13:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=eg4gbJGTcuDjydc93ZgiyQp7rGraJcFEx1C1W41BcoE=; b=h9J8t2jbujSYA51XssuWPT+TwPBC0hpc4NNrexHCEGwQHAuOieOurTwZYlyAYw+HNq ChT2X77bZtwp1CcM6eDjCnR11R6Nh82vxVzBenPkApzoZHHmnp/icFdomknh2OLflAUy 1d2GD4XrY/9bilZfh064seB9+ldnhy1kwCeifrn7Wpt+DRR/K62FTXLnHvLcML1I8N+N vEs4ivWBPRt8itxGZyDoTaMpYd1OW7FewxAuZZ+1KPFPhj///tyVx2puQBqe0yUMia6V MRXiQb3AbFzYVcLbAfWShlNQkoyM2NFNNybmUS/TJgr3ggcERl7PcIWLj278jnUGAbA0 hgsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=eg4gbJGTcuDjydc93ZgiyQp7rGraJcFEx1C1W41BcoE=; b=wBIy+PJMJ1PnnFaejDkS26ubwsVRWH7c1SRdw+utvoJgdw10P7mlgixDqa84C6J4Ox 04RzWUCrseBOADd6aM1mrJs3D6y8mOKB/b7JpTAMK/k/Pg0dW28PwPI2y2LDeJRyzu7K ju5krYHjdnWZKzesR5jFyZOcUAva7xnb8nPl/CafTsgQ4izTldz1As+n6Vm4NB6IqOyk AlkA05HY3KWdk35TYKukQZtUcevDSyjyiEw84Sm/GPpvKNsyv2qREK6P6nQk6+gzs6wg N88asb/X/6fx38GMJB01Ybuecc+mniVQPW5CQH2aF/CwL3uZLFBIJubm1XxxQ5CEVbOW xM2w== X-Gm-Message-State: AOAM531S3lJXfqKB+yghq5W4ljLDQghv23fHuhj6JLXv+KkwG/pWeUPD pNTTNoZA8sBXMpwXQ+IwR3I= X-Google-Smtp-Source: ABdhPJxo7t7sKZ95V5o15r/5Ws72mkjtn0VsMmnL3V3M++Sv6h05ITpulnOCCPrR2+mNheI9i/c2Xg== X-Received: by 2002:a05:651c:b11:b0:249:9504:e929 with SMTP id b17-20020a05651c0b1100b002499504e929mr402051ljr.0.1650052863776; Fri, 15 Apr 2022 13:01:03 -0700 (PDT) Received: from [192.168.1.38] (91-159-150-194.elisa-laajakaista.fi. [91.159.150.194]) by smtp.gmail.com with ESMTPSA id c11-20020a19e34b000000b0046f423c87e2sm260940lfk.173.2022.04.15.13.01.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Apr 2022 13:01:02 -0700 (PDT) Message-ID: Date: Fri, 15 Apr 2022 23:01:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE) Content-Language: en-US To: Kees Cook , Catalin Marinas Cc: Andrew Morton , Christoph Hellwig , Lennart Poettering , =?UTF-8?Q?Zbigniew_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 References: <20220413134946.2732468-1-catalin.marinas@arm.com> <202204141028.0482B08@keescook> From: Topi Miettinen In-Reply-To: <202204141028.0482B08@keescook> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220415_130107_030433_2B137991 X-CRM114-Status: GOOD ( 36.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 14.4.2022 21.52, Kees Cook wrote: > On Wed, Apr 13, 2022 at 02:49:42PM +0100, Catalin Marinas wrote: >> The background to this is that systemd has a configuration option called >> MemoryDenyWriteExecute [1], implemented as a SECCOMP BPF filter. Its aim >> is to prevent a user task from inadvertently creating an executable >> mapping that is (or was) writeable. Since such BPF filter is stateless, >> it cannot detect mappings that were previously writeable but >> subsequently changed to read-only. Therefore the filter simply rejects >> any mprotect(PROT_EXEC). The side-effect is that on arm64 with BTI >> support (Branch Target Identification), the dynamic loader cannot change >> an ELF section from PROT_EXEC to PROT_EXEC|PROT_BTI using mprotect(). >> For libraries, it can resort to unmapping and re-mapping but for the >> main executable it does not have a file descriptor. The original bug >> report in the Red Hat bugzilla - [2] - and subsequent glibc workaround >> for libraries - [3]. > > Right, so, the systemd filter is a big hammer solution for the kernel > not having a very easy way to provide W^X mapping protections to > userspace. There's stuff in SELinux, and there have been several > attempts[1] at other LSMs to do it too, but nothing stuck. > > Given the filter, and the implementation of how to enable BTI, I see two > solutions: > > - provide a way to do W^X so systemd can implement the feature differently > - provide a way to turn on BTI separate from mprotect to bypass the filter > > I would agree, the latter seems like the greater hack, so I welcome > this RFC, though I think it might need to explore a bit of the feature > space exposed by other solutions[1] (i.e. see SARA and NAX), otherwise > it risks being too narrowly implemented. For example, playing well with > JITs should be part of the design, and will likely need some kind of > ELF flags and/or "sealing" mode, and to handle the vma alias case as > Jann Horn pointed out[2]. Another interesting case from 2006 by Ulrich Drepper is to use a temporary file and map it twice, once with PROT_WRITE and once with PROT_EXEC [1]. This isn't possible if the mount flags of the file systems are also in line with W^X principle. System services (unlike user apps) typically don't use /tmp nor /dev/shm (mounted with "rw,exec"). With systemd a simple file system W^X policy can be implemented for a service for example with NoExecPaths=/ ExecPaths=/usr ReadOnlyPaths=/usr. In-kernel MDWE probably could look beyond file descriptors and check if the mount flags of the file system containing the file being mmap()ed agree with W^X. The use cases for system services and user apps may be different: system services are often compatible with maximum hardening, while user apps may need various compatibility solutions if they use JIT, trampolines or FFI and access to W+X file systems may be also needed. -Topi [1] https://akkadia.org/drepper/selinux-mem.html >> Add in-kernel support for such feature as a DENY_WRITE_EXEC personality >> flag, inherited on fork() and execve(). The kernel tracks a previously >> writeable mapping via a new VM_WAS_WRITE flag (64-bit only >> architectures). I went for a personality flag by analogy with the >> READ_IMPLIES_EXEC one. However, I'm happy to change it to a prctl() if >> we don't want more personality flags. A minor downside with the >> personality flag is that there is no way for the user to query which >> flags are supported, so in patch 3 I added an AT_FLAGS bit to advertise >> this. > > My instinct here is to use a prctl(), which maps to other kinds of modern > inherited state (like no_new_privs). > >> Posting this as an RFC to start a discussion and cc'ing some of the >> systemd guys and those involved in the earlier thread around the glibc >> workaround for dynamic libraries [4]. Before thinking of upstreaming >> this we'd need the systemd folk to buy into replacing the MDWE SECCOMP >> BPF filter with the in-kernel one. >> >> Thanks, >> >> Catalin >> >> [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#MemoryDenyWriteExecute= >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1888842 >> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=26831 >> [3] https://lore.kernel.org/r/cover.1604393169.git.szabolcs.nagy@arm.com > > So, yes, let's do it. It's long long overdue in the kernel. :) > > -Kees > > [1] https://github.com/KSPP/linux/issues/32 > [2] https://github.com/KSPP/linux/issues/32#issuecomment-1084859611 > >> >> Catalin Marinas (4): >> mm: Track previously writeable vma permission >> mm, personality: Implement memory-deny-write-execute as a personality >> flag >> fs/binfmt_elf: Tell user-space about the DENY_WRITE_EXEC personality >> flag >> arm64: Select ARCH_ENABLE_DENY_WRITE_EXEC >> >> arch/arm64/Kconfig | 1 + >> fs/binfmt_elf.c | 2 ++ >> include/linux/mm.h | 6 ++++++ >> include/linux/mman.h | 18 +++++++++++++++++- >> include/uapi/linux/binfmts.h | 4 ++++ >> include/uapi/linux/personality.h | 1 + >> mm/Kconfig | 4 ++++ >> mm/mmap.c | 3 +++ >> mm/mprotect.c | 5 +++++ >> 9 files changed, 43 insertions(+), 1 deletion(-) >> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel