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 39E59C38142 for ; Mon, 23 Jan 2023 16:10:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75FE26B0072; Mon, 23 Jan 2023 11:10:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E8BF6B0073; Mon, 23 Jan 2023 11:10:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 562AF6B0074; Mon, 23 Jan 2023 11:10:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3F9536B0072 for ; Mon, 23 Jan 2023 11:10:16 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F3278120439 for ; Mon, 23 Jan 2023 16:10:15 +0000 (UTC) X-FDA: 80386550832.01.47A986A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 5F05F120015 for ; Mon, 23 Jan 2023 16:10:13 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HhPsctVL; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1674490213; 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=uaz2eFwwKZQeqzaBnyjvTh9KlIDFMudiVk4t+F3NjSY=; b=coy9jgrmfyJ+7FrONiUk0LBVuR4u9q5xa6Z0nuiLZG52ma/AKeXtSFt+eDc/yX/hDOpy+Z 7kU9eTxg9jj+6zVwUxv+NDH58MAMxuwU/MFTh0g6DkLw6Q6h/q76Wvz/QV1wBMLEW4x0zB 7SW4baCgRc+u8Wzt+xttDsIjsleLNos= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HhPsctVL; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1674490213; a=rsa-sha256; cv=none; b=cn77RO3gBE6BNEYH69BP9NGz7ZKovYl7EyRKtHg4jb0LCAGGBPY0g2hmai8KXM6oofYuJ1 qvwhEFxI5lo2Y6HcAH74eer/dSzzuNC8Ro/N6WlPHeNkI6QxwV2UF/C1BtzB03yTbRYloy TuUuWbPESn+ekQmDlCjKNdj8nrMj+Z8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674490212; 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=uaz2eFwwKZQeqzaBnyjvTh9KlIDFMudiVk4t+F3NjSY=; b=HhPsctVLubBtMCCLXTl/AdJe/HXeZFVPEzFbP1gzBSpycmof7mKKZ19h6aymrc9LDxsuuV L3Xi4AmL2EuNEEEujSIrTPsh/ykHiPpIwEJirQCir0eQ0ts6umjs5RHaVcfFIoa/Ld8Z9i pHhV9l0VBjm1+OFEFraZ7rVDN2N+vvw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-339-Gh1NGn8NPz-ambYS23Aidw-1; Mon, 23 Jan 2023 11:10:11 -0500 X-MC-Unique: Gh1NGn8NPz-ambYS23Aidw-1 Received: by mail-wm1-f71.google.com with SMTP id o22-20020a05600c511600b003db02b921f1so9667902wms.8 for ; Mon, 23 Jan 2023 08:10:11 -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:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uaz2eFwwKZQeqzaBnyjvTh9KlIDFMudiVk4t+F3NjSY=; b=TMjNrzgpV3sqbOsJy0c83ME7zsfnj9X/bUoxBlw//f7/887rq4rnhRONOS4xLxSi/u Im2MTPB6rf6GU8rBy1pEVyK9S2AlC4fhUmaER4wp46K0dX1N+uhvyl0e1hIFEAJ1eXg4 fGPIsxB88I6gSKmESUdj0ZzPQbRDih+LizQZdPJo2ftQ0ffO0hGdM27G0zp4EurpOKms gWn5WZ89NYTZFP3k9FfBfegp08eJ0ZZiVrZ4ic7V3X59hLSkGhQAK6D6JvmZM/aazFAA BA6fikdsuHyWrqQ9w6YvQM+LWJGqhOERa6X2DKVm11C8AF/MiZB3WszLPCSbXxDp9mln 7Psw== X-Gm-Message-State: AFqh2kogr9maMm+dNaXi9Bxd+b49oG5KpIS6lPhfBoht90mIk5Dy0KN9 570BqMiKrd11GWb/VrGUchUykckHOJGE7+IKNpaRut6bfGEUgrVztWGu7jOIiLrpIMYZDbIYqC0 zDAd1++1Quw4= X-Received: by 2002:a5d:4703:0:b0:2be:5408:5d6c with SMTP id y3-20020a5d4703000000b002be54085d6cmr11570112wrq.25.1674490210339; Mon, 23 Jan 2023 08:10:10 -0800 (PST) X-Google-Smtp-Source: AMrXdXshtGaRKAVI126HK3VLdPO+gptPTBr2easvP2Gqa9Z3J0by8Blo1tezQKxtshHAuSHVh0wtaw== X-Received: by 2002:a5d:4703:0:b0:2be:5408:5d6c with SMTP id y3-20020a5d4703000000b002be54085d6cmr11570084wrq.25.1674490210013; Mon, 23 Jan 2023 08:10:10 -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 o13-20020a5d670d000000b002bdc19f8e8asm30883764wru.79.2023.01.23.08.10.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 08:10:09 -0800 (PST) Message-ID: Date: Mon, 23 Jan 2023 17:10:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v2 1/2] mm: Implement memory-deny-write-execute as a prctl 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> <8b4e31cf-de20-703c-4b53-ad86d4282a37@redhat.com> From: David Hildenbrand Organization: Red Hat 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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5F05F120015 X-Stat-Signature: hxtmkaowjjk19ew53knwjfz4cryn1zd5 X-Rspam-User: X-HE-Tag: 1674490213-263829 X-HE-Meta: U2FsdGVkX18I1fAAXJC1LvXjPNjEJMkBeaXu6w7x1E1isfUAQ5ozQ7sn25w3fPQ6mCMpD/e4TVp7KuqL0UnpsuaFqHCe+BTFC45VstePGzWfjuSaHmgvrJQbsYhf/Xa3jRanA/IIWZ3Tpn79hT14i3Et/wi7DRWbMxtn6KqALyB50nLwZsZ1XRpckPqV+1cuH+yYASCd0aV8DmEkYgKq+TTHv2z4VQ4YdfcCrQUYMxCCIKqLH0tQtLk+3I+yTBanx6erO3QGSyGrPlf1wliojGdgePn8vvtA2dSVxkubp0qDZRoUPxPyoroRddActlpzT/gG52VM49R2L0Cmx/dEh2oEHhyW/haRvBE7I8nR0TALUzFrdt7MEAiuhC3zpjWDbqw4VwF4cDLYwe8uRAoyKfUl183J6NxyfjcF4eILailHoh0jeLAot01leYAr1ZbF2jw7ncU41nfZn/D1Eaz7G7pGzV8oVoa+PQ7nZWysUqyqAW/rCpRkOtIIHsWYKXo2k1B7RxglOZyCEwpd388m7W/smdhI0JA4/DNEXkIXCPMYPbPz/uDeWvf/+9EBK/FRZbxO0GNsb20UlQTwX+kNIR+4nknJ4y3SCqvAvX12B3seCm8bMdsLDao+StDSByCtrmBKtuEJOlFtW9hGziWhVPfVSMwkz4FP2/5R9OdM47JARW4hFaYnzVlf/RWWYIL6EWPu8OwArJlAB+amE1IlMANIjR633x9ar5N13NxqbLErBAAmztTwIEbRbuWSLajWi75cjlCDnTCnqegJ3rlbrN9tpqQZFHiuOgzWyWsJ57C2ILcrkQ+AYR4QKQsfqJDX3qNJLDEeveyNoDWfE1rxXkoHlskCYDDFL82OPjrLprkSzgRJM06tPPDSo135PsQn1HbVJxm5s8TXQ3SKEvYwFrq2DSfHci06AKhjF6yz7/RqlefLyx8CATKapqwY0k9TIalB3k9TuzY7sM54Vze rJ8J3f6O I2RUGHjr+DBytWUg915UWDyIgOEtwi8NUvy/v3MqghfRI6c0Lad/pDVjCyF1Lr99LWJXDi+Oe41vOtw7MCcjHCzrSMwIy2refsZVC2dJDTQGHlwI7pSQdJQ1NxCLpPjz23EZnrMTAzuBRQ+FWB4U4syJdZElVea84uxnBo/adTHg3BoLXHjsyW+OfuS94rTsCpXshLYj60paiF3WGAIBajG3bXH4GW2AMrXMyzOvD1DJjp/VTOFRo/wvdaQhN0OyqJ8qSDFrjGeowfdEmnovU1Ol1z5E+TC5OZBNigUZFtsskJsiGVT3TY+hZhVeAz0AZcQIoWPgaT5KJA4YBpMDA1DB+KXkeybU6YGd9cDP7hXzGjgl8aTjXZU3ITUisJRKAOSB7L0/5hPR1kmrPnqGrXynrMw== 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 17:04, Catalin Marinas wrote: > On Mon, Jan 23, 2023 at 01:53:46PM +0100, David Hildenbrand wrote: >> 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: >>>>> 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). > > This should work but it doesn't fully mimic systemd's MDWE behaviour > (e.g. disallow mprotect(PROT_EXEC) even if the mmap was PROT_READ only). Interesting. > Topi wanted to stay close to that at least in the first incarnation of > this control (can be extended later). > >> 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). > > Yes, both this and the VM_MAYEXEC clearing if VM_WRITE would be useful > but as additional controls a process can enable. > >> 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. > > We still allow VM_MAYWRITE for private mappings, though we do clear > VM_MAYEXEC if not executable. > > It would be nice to use VM_MAY* flags for this logic but we can only > emulate MDWE if we change the semantics of 'MAY': only check the 'MAY' > flags for permissions being changed (e.g. allow PROT_EXEC if the vma is > already VM_EXEC even if !VM_MAYEXEC). Another issue is that we end up > with some weird combinations like having VM_EXEC without VM_MAYEXEC > (maybe that's fine). No, we wouldn't want VM_EXEC if VM_MAYEXEC is not set. I don't immediately see how that would happen. > >> 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? > > I think currently with systemd's MDWE it still works (I haven't tried > though), unless there's something else forcing that file read-only. Okay, just curious if this is an easy way to bypass the MDWE restriction. > >> 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. > > This will break __access_remote_vm() AFAICT since it can't do a CoW on > read-only private mapping. Yeah, might require some thought. > >> 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? > > They are expected to continue to work. The prctl() is meant to be > invoked by something like systemd so that any subsequent exec() will > inherit the property. Okay, thanks. So it's mostly about new processes inheriting that restriction. > >> Clarifying what the expected semantics with /proc/self/mem are would be >> nice. > > Yeah, this series doesn't handle this. Topi, do you know if systemd does > anything about /proc/self/mem? To me this option is more about catching > inadvertent write|exec mappings rather than blocking programs that > insist on doing this (they can always map a memfd file twice with > separate write and exec attributes for example). I remember some work regarding forbidding ececutable memfds. -- Thanks, David / dhildenb