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 AD5F4C38142 for ; Mon, 23 Jan 2023 16:32:22 +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=8ZFbBEwMwn1VMYVrjAQW4ZgMJqIpu4UClETn221Nt00=; b=QoXQh9gMYFfA/W kePrG8jZyCIrDivV7NvRMCFgqLl2V5leFjw74UmlIwm8zwfT8qSMDST+nhpDvpPSz/DEsSKGB6Ci1 N26P/gMyIVT5at7Y9DOqXHTNXhWHG2teafnaUtY1xZmguJ3BDHNH53c1RWKE62V9K7EPoUgOzBYMQ fRBdhiWX4xR+xohql/QDUBxRalzMEEL0xKJhZXH56mlBEHvsW62PtVGAtDP/TgMidp3SbFucrP8gL Oiw+uLZV4S/y+FYOPj2+e+jIvmKqdmLxReEUIMqZ/IVDQ5P8ET99eVZyBXj7SyZ2UH2zOeZPPtxpc 1u8ceR4g9y7PzHOysgdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pJziT-000YNY-OS; Mon, 23 Jan 2023 16:30:42 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pJzOg-000Rb1-8h for linux-arm-kernel@lists.infradead.org; Mon, 23 Jan 2023 16:10:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674490213; 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=KRXIFTog9TqXhCCBDnRinSvB5Re4iSrjoPqF9mKLlxGISmx3HdmK/YIl/AHyarFBsovxTA 5dujvCDK5/4dTjyg0FBT4SsNHCCOAaoGmgdrhq4/1QKFmUUkfKs7zKCpMGZF4KgrUy0Dvd z0JwICKFDuVfkCOX+8bLuA5l/VYukH8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-300-4bueOHdJPvinnVpENvfPPA-1; Mon, 23 Jan 2023 11:10:11 -0500 X-MC-Unique: 4bueOHdJPvinnVpENvfPPA-1 Received: by mail-wm1-f69.google.com with SMTP id ay38-20020a05600c1e2600b003da7c41fafcso9679704wmb.7 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=EpsR7/0Ko7XGTUAnDWc2OQxFNN9mHckxybewz7zZfCHIV42G5TaTeMgPdmlrHSOFzI CxAWQZEdjwULtIB2g4r6n/0MZ8fbadeXBFzeJjKD1740264bZHpZo0Dpozs/c49X2Pvr DoclPVA9XvyhLphv32zAG/2RufLbLX9ddDJd2R4Uxuyk1jzTAXad45ms3tm1m5sprzLW aYBJaCVFWG2gdUj/QsRG2gvcYreL1tK4H0Eo8+9vMz5KtiiliRkopVGo62F3MPRSAgmT I/zlQ0NiymBAvpDfB3XQX15qqYUl4CrWPHjs6peQA/4VIJAKyy8+l4Jl2hYTlDkPPpCY 1xsw== X-Gm-Message-State: AFqh2kpkg6UUHBelf4VX9adk9f5l/clpY4LlSAkjl8nUs3nKM1JdE/St MF1+dDPOSYS82cK/ncRFJZdM9WVbLd9SA4qTVuYcrfyPqo2kNtwE7BGKb/FHcSLGwpZsSvnj2zv vl/DV210pmoLD63p7mxUjL60CdplAohEAUlU= X-Received: by 2002:a5d:4703:0:b0:2be:5408:5d6c with SMTP id y3-20020a5d4703000000b002be54085d6cmr11570110wrq.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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230123_081014_455532_DAD144C1 X-CRM114-Status: GOOD ( 43.53 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel