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 90F6FC54E94 for ; Mon, 23 Jan 2023 12:53:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0D296B0071; Mon, 23 Jan 2023 07:53:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBD016B0072; Mon, 23 Jan 2023 07:53:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C902B6B0073; Mon, 23 Jan 2023 07:53:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B86FB6B0071 for ; Mon, 23 Jan 2023 07:53:54 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 850191A0881 for ; Mon, 23 Jan 2023 12:53:54 +0000 (UTC) X-FDA: 80386055988.04.592EE77 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id 01482180014 for ; Mon, 23 Jan 2023 12:53:51 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GLHXRexo; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674478432; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VBYV07fuEsbmrQz4pa4SyZyORm3t80BZlJSUiqj12qg=; b=imX8CJs/I35xjiEItoQxX/XSVenvHXLrwEqf5p0MMQ515ZkKm1Tkwjoz1JnLxLdWYLQSyB I94WcqFheYO5j3On+3oEi0aw9GiCSMHzMlB2S023dGO3zTNoSk0Es65jKxPYleMPRr30bD kzwNRQvhk8PJ+YAlhctD47sIs3HOf8E= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GLHXRexo; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674478432; a=rsa-sha256; cv=none; b=nBotGljyokokyqXlOJ7c4tY+rorkg/owxrm93z8tMwTJ+HxLK8joJiuQyfO/wRpb5UUFRI RGs/jmKHZLx6ExO5/+zJHkp0z/ZtiVsWw6e1p6d9AvoveXSmlN0W+IgaPFGWgO0gOjgY4C vEF1upafTj5kzfBARyY3Tu2aud7yV5U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674478431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VBYV07fuEsbmrQz4pa4SyZyORm3t80BZlJSUiqj12qg=; b=GLHXRexo7We8YSSijQ3phmW5yAGzq67/c6XzXIzj6lw2tqVLKeHKncQr9T1PEcabYmmV/j Tyl0ff2eGUAxFxj7OktoDiFT233Dri5qMRLwiorJqIh6WPxr9Nx32u4VjvkxZ3buZUDCC7 cv7GlgcxyDeWFjoACKihfbV57MXs83M= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-20-eexDP0hROwCOc7TkK3ME0g-1; Mon, 23 Jan 2023 07:53:50 -0500 X-MC-Unique: eexDP0hROwCOc7TkK3ME0g-1 Received: by mail-wr1-f72.google.com with SMTP id b15-20020adfc74f000000b002be276d2052so1950061wrh.1 for ; Mon, 23 Jan 2023 04:53:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VBYV07fuEsbmrQz4pa4SyZyORm3t80BZlJSUiqj12qg=; b=QjKRQ4nYsIpjNYumqIBHbQMdbIweDINQ2wPYW4MbmioniIgPUAquxbKcQ6agoxq/aA +TIheIvi3EDhdPhGO6F4c5WmKy4GScVEbCp8BJYZLJLaP7C0qpH6dnfK0vZIgARwGgCk jH/RU4k2TY1Kk5sCoAy3yP4R6B69Je1mkjB+Zgqg75FgIps9Oe+njXJdzi6gh+KI7ESX nlORItGWh67v5G52BnuoUrq3wt3i8IVsWGEfBgRws6WWzwFGY8X/XuIzUs3GWXGM8q9K BxIyUTcahuBQS2mEkkk29nYy0oTUjpQ8rhQ5qr4plX/lT9ZBu0hX8eo1nKXY/ibN9Vxt F8Yg== X-Gm-Message-State: AFqh2kphQAD4wIwoJhN8IEJ+pNOgc2/3WkFcfUbRzxOt579WeyUabtnm yobVHANOYJEPCZxruG+jmVzufc6+hw2W+7RjFa7zD1mxfIsx8cdFdXhpsSAgr9FztH118/Ygepo qGzbQpQxsCZY= X-Received: by 2002:adf:b604:0:b0:242:1809:7e17 with SMTP id f4-20020adfb604000000b0024218097e17mr20678774wre.6.1674478428844; Mon, 23 Jan 2023 04:53:48 -0800 (PST) X-Google-Smtp-Source: AMrXdXsSg31BoPLMpZ6IuIfrhN9+GOXK1ForpDTK64UwrPOLXwlLdkWdfdykNreoZBg9BBBig0d9Vg== X-Received: by 2002:adf:b604:0:b0:242:1809:7e17 with SMTP id f4-20020adfb604000000b0024218097e17mr20678755wre.6.1674478428504; Mon, 23 Jan 2023 04:53:48 -0800 (PST) Received: from ?IPV6:2003:cb:c704:1100:65a0:c03a:142a:f914? (p200300cbc704110065a0c03a142af914.dip0.t-ipconnect.de. [2003:cb:c704:1100:65a0:c03a:142a:f914]) by smtp.gmail.com with ESMTPSA id y1-20020a5d4701000000b002423edd7e50sm4320205wrq.32.2023.01.23.04.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 04:53:47 -0800 (PST) Message-ID: <8b4e31cf-de20-703c-4b53-ad86d4282a37@redhat.com> Date: Mon, 23 Jan 2023 13:53:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Catalin Marinas Cc: Joey Gouly , Andrew Morton , Lennart Poettering , =?UTF-8?Q?Zbigniew_J=c4=99drzejewski-Szmek?= , Alexander Viro , Kees Cook , 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, nd@arm.com, shuah@kernel.org References: <20230119160344.54358-1-joey.gouly@arm.com> <20230119160344.54358-2-joey.gouly@arm.com> <4a1faf67-178e-c9ba-0db1-cf90408b0d7d@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 1/2] mm: Implement memory-deny-write-execute as a prctl In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: oiwyhtno4qt3trci38ma3q1ooadwzxhy X-Rspamd-Queue-Id: 01482180014 X-HE-Tag: 1674478431-922117 X-HE-Meta: U2FsdGVkX19iHcTZicjKI+bAUsO/V7/X2poIikMxZ+LHVK/e6kb3V/YLaYnJkZ5I6sHA4a9GVpmLwBZDacHqECrm/wx1OpyXfY5FshWRdJdNBqkbZ1dI4Y38jWjLiyHgKDzkSQortF/6fWW+jk6N2jHQlENJzbnH1NVUv5nLG653DgrqgRiVFTsRA2Qq9D7zurx+b+FQK95BW5eJ9gt9+xdcZI58wg4S+IvXmAFMtTpa9GAv/5AXQbWNPu86U48ZOOdDowqr5DImCLcFZ3nanei7j4b3z727QZBuegBle0bDVqcv7c5/rTsuSoHmM0XAV5Dke3Mje6f/izhxIrAYGhcxX08sAfPRPv7A2BG9j3loAxDHwIoHQA8aPN43N1gqT7pS0GIaPWBbKFeFJGQrBbpWkiS2mfOLb0VZAnM/kaerKGgF/rrVUpXmJisD9k/9maQULUWMK6Hd5jFU2xE4iWFK226sQe83EEBhUEdEioGrtT78n1xogDJbLt/P4J1r/MrmSHzTzIWVgqKh0raEs6hN6yB9wxMgcxHPmmVPWnbrUM8dmMWb7/sXzxyDR5nKSr7zfFvoaFL8y5vWSyT/NqKyqGb3X4CtW41Hh9dIszl8JY5BTUGX6MFJZKSIGXAL9flyidzpC0AM4ZQkJxV4HP9us/7srhJy7VFCkq+OBlGavbpCb+QrDAwn50uSVWoAC66HwW2G8QEM3YFiNNzd1k5GvRE55VYpIBg43mBVYiZU9ihC25XBgMJdCZkmnquSX01UP3b3KtaM5H+F2WtNpONjQNH48Zu8u1wicJvj1XJi4qTZVPOJp2p7qexSle0w5cNOdq6B5houN4LTK+KmqXdIqjHADuApblkUinn07T6DaRSRkmHbLcid3kABKmQD81/Id6AxruD7g6A3MQq8tf+85TKMfBGCgnbudOXNBes48eCzaFynC70gMdj+lGGHMTbOBXMpwS3kpVuSesW TS1ZZQPi gW9n1jtHbPSWxpL8ess1TumUomM3hThzrE6FZowgF/rMl4eEAi+Twy+9kFuRfGztHOt+Y/tEwhW+XX29fD5YzWGASqkvvzLsP9KtRrLrkMHIEsDMfZDdBheQiX7Dg8VD+qWhBWhnp0MgWPKpAkNUClSiEIXLdqcP5q+Lj8XhiChVJ3T3JhPCKQkw7o4LgNe7FknGL/o6kBwkDrjELqHBV3B+FDB52E+PnZgcJPjSCYJjXcX6xhcvKrdGy2boOx6Pg5CsoOt2hUVKiJspgF7MneXUNd0F9tFs9n/9nuZHhd4CnQCZDBXFFXDDwEhP1WcwUS+7u4QrsgU56wezbDgfthfHhT7lhvxP2iuPwP/nReaSQopQ5VNxn0SKvfpsjsrnZYra544woXa4NBvKzbbNEUbrs2Fw5sU3aNcwAxcQPVrFQveGKGvsk/QGKhD3Rap7OBefmW2f/Dv4BWKBbE/z36qtlFbxDx6+OR4ppeKQ6B8+zt95m2aUcN49Wh2v44ywrA2ChMsoFm32yLAk= 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 23.01.23 13:19, Catalin Marinas wrote: > On Mon, Jan 23, 2023 at 12:45:50PM +0100, David Hildenbrand wrote: >> On 19.01.23 17:03, Joey Gouly wrote: >>> The aim of such policy is to prevent a user task from creating an >>> executable mapping that is also writeable. >>> >>> An example of mmap() returning -EACCESS if the policy is enabled: >>> >>> mmap(0, size, PROT_READ | PROT_WRITE | PROT_EXEC, flags, 0, 0); >>> >>> Similarly, mprotect() would return -EACCESS below: >>> >>> addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); >>> mprotect(addr, size, PROT_READ | PROT_WRITE | PROT_EXEC); >>> >>> The BPF filter that systemd MDWE uses is stateless, and disallows >>> mprotect() with PROT_EXEC completely. This new prctl allows PROT_EXEC to >>> be enabled if it was already PROT_EXEC, which allows the following case: >>> >>> addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); >>> mprotect(addr, size, PROT_READ | PROT_EXEC | PROT_BTI); >>> >>> where PROT_BTI enables branch tracking identification on arm64. >>> >>> Signed-off-by: Joey Gouly >>> Co-developed-by: Catalin Marinas >>> Signed-off-by: Catalin Marinas >>> Cc: Andrew Morton >>> --- >>> include/linux/mman.h | 34 ++++++++++++++++++++++++++++++++++ >>> include/linux/sched/coredump.h | 6 +++++- >>> include/uapi/linux/prctl.h | 6 ++++++ >>> kernel/sys.c | 33 +++++++++++++++++++++++++++++++++ >>> mm/mmap.c | 10 ++++++++++ >>> mm/mprotect.c | 5 +++++ >>> 6 files changed, 93 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/mman.h b/include/linux/mman.h >>> index 58b3abd457a3..cee1e4b566d8 100644 >>> --- a/include/linux/mman.h >>> +++ b/include/linux/mman.h >>> @@ -156,4 +156,38 @@ calc_vm_flag_bits(unsigned long flags) >>> } >>> unsigned long vm_commit_limit(void); >>> + >>> +/* >>> + * Denies creating a writable executable mapping or gaining executable permissions. >>> + * >>> + * This denies the following: >>> + * >>> + * a) mmap(PROT_WRITE | PROT_EXEC) >>> + * >>> + * b) mmap(PROT_WRITE) >>> + * mprotect(PROT_EXEC) >>> + * >>> + * c) mmap(PROT_WRITE) >>> + * mprotect(PROT_READ) >>> + * mprotect(PROT_EXEC) >>> + * >>> + * But allows the following: >>> + * >>> + * d) mmap(PROT_READ | PROT_EXEC) >>> + * mmap(PROT_READ | PROT_EXEC | PROT_BTI) >>> + */ >> >> Shouldn't we clear VM_MAYEXEC at mmap() time such that we cannot set VM_EXEC >> anymore? In an ideal world, there would be no further mprotect changes >> required. > > I don't think it works for this scenario. We don't want to disable > PROT_EXEC entirely, only disallow it if the mapping is not already > executable. The below should be allowed: > > addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); > mprotect(addr, size, PROT_READ | PROT_EXEC | PROT_BTI); > > but IIUC what you meant, it fails if we cleared VM_MAYEXEC at mmap() > time. Yeah, if you allow write access at mmap time, clear VM_MAYEXEC (and disallow VM_EXEC of course). But I guess we'd have to go one step further: if we allow exec access at mmap time, clear VM_MAYWRITE (and disallow VM_WRITE of course). That at least would be then similar to how we handle mmaped files: if the file is not executable, we clear VM_MAYEXEC. If the file is not writable, we clear VM_MAYWRITE. Clearing VM_MAYWRITE would imply that also writes via /proc/self/mem to such memory would be forbidden, which might also be what we are trying to achieve, or is that expected to still work? But clearing VM_MAYWRITE would mean that is_cow_mapping() would no longer fire for some VMAs, and we'd have to check if that's fine in all cases. Having that said, this patch handles the case when the prctl is applied to a process after already having created some writable or executable mappings, to at least forbid if afterwards on these mappings. What is expected to happen if the process already has writable mappings that are executable at the time we enable the prctl? Clarifying what the expected semantics with /proc/self/mem are would be nice. > > We could clear VM_MAYEXEC if the mapping was made VM_WRITE (either by > mmap() or mprotect()) but IIRC we concluded that this should be an > additional prctl() flag. Yes, I agree with enabling this restriction on a per-process level. My remarks only apply to processes with this toggle enabled. -- Thanks, David / dhildenb