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 7AA06C433EF for ; Thu, 14 Apr 2022 18:53:51 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HIkYx4foYtVvfpWWx8/RwGv/bpUY7pQBblf7BqGS7RM=; b=TjWXpk2BQdwsZX OziTX+ge8unKq6cCemvVmm2Y+96AYsUxkiaJENF3TvAbIdNVZFqa+zGMyWlMxiNTrLugf4DzdIISv 4NbVBKUJKGa51dMMRUTBxo/1PzoSdFXX18b/tshqGQN4xfVzub74sK4qs3Ku1403Fpa0ldJwMMHuK +n2qXDw1hehaLeNMcU3/f1rm+T9SMuOdi5jN0/jCGpmTbjFIPB/Ndvie/a3RvfhRDaToSmr4OeeHn utOf+DVItOV9UUCJ8zetrJhK1GyDcmP0tEFXr6RdX0iMqV4gp/yj8IWliDgLqYwxslEGhaUVowEwL ylsVdKLCCvpod0B2j4gg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nf4Zs-006veH-VD; Thu, 14 Apr 2022 18:52:25 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nf4Zo-006vcU-Li for linux-arm-kernel@lists.infradead.org; Thu, 14 Apr 2022 18:52:22 +0000 Received: by mail-pg1-x535.google.com with SMTP id h5so5512301pgc.7 for ; Thu, 14 Apr 2022 11:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KPncbYJNbA92y1tOvGAA/kfwDjyfM1X8IrkxMDKfJ+M=; b=oNJvsyY0dZL8jzpd34U1+lD1Mh8SQf6LfMh/R2x0RNJXbEdp0Xg7P85/Y+6PQt0AES rhaP4cro55hlKlnS+hw2JRDJMYhHFgA8+9OIE42iBmqFG6lmbZCLPNkLehXQLN21cuOM 91/dtOApOgZJLABiR/avAVberdE2aWu4pBxhU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KPncbYJNbA92y1tOvGAA/kfwDjyfM1X8IrkxMDKfJ+M=; b=TUJFYp2GEa3mUzDQpBXtY2uH0ZjaAoYc9j1M3alnB7Hom+dAglf/rc46BZwF2PAwok 9BQRMrQSPhM63b3Sa8V86k5CECRKAWW4FoeQa6HC7TKrONe8XM7Bq2pPCjXzvauvlhwf UTx6eKWMt9THyfhnFEVx8Ki8wNutmpaVawtrwh0LzcX7J1PcGlo3qOLGOsDVPgMm1zkf rodOm2AN8wu0MQ9dNnZZby2NkyxdqpOhdc12QygO5/4IyV0AqTYgle5PFUQlinAMaqKG E1N11Zaisz1JoCJauprpEXN/+m878ApDHUah9k80BNbtJnv/cwjw5CGZcILTn1QbpBRW SKxg== X-Gm-Message-State: AOAM5325xdIVcM7BmfTTJlscu4hXF3NA9fS3SJVmeTR7OSHDF7EyHYTg /oHvygpXfrgta0NgZCoqMNjQ+w== X-Google-Smtp-Source: ABdhPJw+Fal9pBni7mp3U0SmabFGXSbaUnm/vG5K31I/eUCpSn6eG3IceNt4WGY+Pb6rg423uVG4qg== X-Received: by 2002:a62:1548:0:b0:505:fd84:33f1 with SMTP id 69-20020a621548000000b00505fd8433f1mr5299523pfv.66.1649962338843; Thu, 14 Apr 2022 11:52:18 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id c64-20020a624e43000000b005081ec7d679sm613192pfb.1.2022.04.14.11.52.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 11:52:18 -0700 (PDT) Date: Thu, 14 Apr 2022 11:52:17 -0700 From: Kees Cook To: Catalin Marinas Cc: 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 , Topi Miettinen , 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: <202204141028.0482B08@keescook> References: <20220413134946.2732468-1-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220413134946.2732468-1-catalin.marinas@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220414_115220_768236_A2ABDA00 X-CRM114-Status: GOOD ( 33.62 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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]. > 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(-) > -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel