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 1DFDCE77188 for ; Wed, 8 Jan 2025 22:07:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EB6C6B0085; Wed, 8 Jan 2025 17:07:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9743F6B0088; Wed, 8 Jan 2025 17:07:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 814B66B0089; Wed, 8 Jan 2025 17:07:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5E3976B0085 for ; Wed, 8 Jan 2025 17:07:30 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 11E72121576 for ; Wed, 8 Jan 2025 22:07:30 +0000 (UTC) X-FDA: 82985671860.28.ACA4124 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 52879100010 for ; Wed, 8 Jan 2025 22:07:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TBzY9i6x; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736374048; a=rsa-sha256; cv=none; b=utpfUmAL9AtcrLs7x0RSWEyQEPYXvhmgKhNQrbDqOui69wA34iWdEa/i85uwm5Y0R7f+ub J1CMV+ZVIg4oorIcPuENkI2k9hnYWhiwPUDc2H1eueTedLMuRWk45lyilliD1P//QRSLWk pyZU1r91mx3GfGlMlDUwlpJuMZ+SbMM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TBzY9i6x; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736374048; 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=2lNkkKHQ5+NGXaHRJLxjGO3L7Qv+D4T5nKOTWz1k1M8=; b=Rnn0elPv9vyBhMi6EErc1lVF9GFeqntJ5pnHIAo6lFWNxzcmrYeF2fNVtObMD9ta63dCVE 9zDXmarRBu8kHZy0jWaUpMhpa8vM/Vwvby3Z1CSk2qP8wlLf34v23uzpE1T4OW+YtyGrsx zLE9AOkSot2zkmo2IlSG8Q4uPURAkjk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 32E365C580C; Wed, 8 Jan 2025 22:06:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2DB1C4CEE2; Wed, 8 Jan 2025 22:07:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736374046; bh=HZMtphnmGpO98shKkSgLqE5zhCeRjx5Z8omYdITC2Lc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TBzY9i6xZm7Q5qxptV4de0bTHK7HCunPfhrBNUQilnqhL3pZE+uI0vC/9Pb7nI8Ms FS8iAMLQvjEGMcujFh/LA+mxhbxR29d0J1gJqXDXpRffnKNCwE3LBt6jOyxTdF+Yys qMPXKnuDdo+prruBE41e9QgBLCiyzcxHxC8v/A29S5ThSsGfnKb2xG/pZHQDj9MVQI CoC1lwV9dUHE3GN2FJ65TIcr2tyzKf/WC619/o4n6hUvk2je+b6VXXRdZ/1C45Waa/ qnsEHu4c/gnLxSthwJ9xKAucthsZXBYgmlO6MOjihIray8iTnJHMz/87HNp2pEhDMy J661iaYTv1q4w== Date: Wed, 8 Jan 2025 14:07:23 -0800 From: Kees Cook To: Lorenzo Stoakes Cc: Jeff Xu , Jann Horn , "Isaac J. Manjarres" , Andrew Morton , Jeff Layton , Chuck Lever , Alexander Aring , "Liam R. Howlett" , Vlastimil Babka , Shuah Khan , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, Suren Baghdasaryan , Kalesh Singh , John Stultz Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd Message-ID: <202501081358.3EF3114D6E@keescook> References: <20241206010930.3871336-1-isaacmanjarres@google.com> <20241206010930.3871336-2-isaacmanjarres@google.com> <0ff1c9d9-85f0-489e-a3f7-fa4cef5bb7e5@lucifer.local> <202501061643.986D9453@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 52879100010 X-Stat-Signature: pd8dxn5dgszehbiw7wysmqzoj7uy5onp X-Rspam-User: X-HE-Tag: 1736374048-67780 X-HE-Meta: U2FsdGVkX199HqR1/rjfmqXioA4oF+KMMxsaFKGtEZnOHaHReEvLXrZN0Z6r5VZrzegVmXFvqFxyBcQU/nUo/zQhS+1f+kbjNscSQ/85evBgh4MGEtUUE9ZBjCHfg+7XkRO5PAh+ZxPnnaSbj576ySH0GitAe3liiYCT9TncT/do7yp4tn3rpbTs8tDZKny16ZGuDUtElBAkIHuAYO5ZErrTEkg/8gVRb/UvDdYoELOXWCSWT3gZ0i1i5ToEYfl8kZoHbHZDpQdg+xxzWf+4/pSA8NYetUtL3lOYJf75+Pf4ACWPMMlogMuMHFNJrl8/XIYlWiTOeqv0Unn6iDJOoR0Y1g7Q7iPYhYFagM17vYcpH7kqAUK2kni+WdILvZ5uM6zaTf0EDfKl4wMk+Znpi0B0QwFCMDgu4iAxexjgvgu1YuoeCwtgjYKWReUzFXmF0GJ956jNFRtUOzHb177Zef6APvVGDCP1JS1gr6itlgRIBt4Ebb/tQU4oAGz7L4fblw8nRB74yz4OykB6OgjOlvsNn1oPKwnhJbqfirNk3oCD3QhbEbLwLF7f6C6eXPysIPbY+Wef22IIvuepR68yFy+KQxXFXubf2y/XAB4Torv7wO23MWyUeWfk6zAZGuJb2wM4ZWLI/GkBgfahxlIVtJNbv6dWN65jQULjx/4ten37xPXoZq872YCGrE/aSmo7vrXDY3UXZ8IECLhHDqwSxRjU0Yh7E3LDsGeiIqqPKlMP8NmYubaXdiXUxnBTqO0WEj1QDLA/qJ5PrZn98uxaA8Jm35Qp8GNc5CVYjJTkJvSwlt2bCUFVm8rlYLdyorp/x33d0M6mPBhtI0Ibmgkmk8ZdkV0NUFIjx7hPrZiaUTRph6h+MKj9fID4ig1SAwmZIICwkXqGWkgK/reSPcMy0gaC4Uo7ALrPYmZ7jXlfSohnZ2jbSaIcd/C1yaiQZWJJpd3udw6a+5LzZNszIy5 6XeVuuC8 7QpIGbiQXS2TbAVNQ9q0mIhtUCApHIjMxI3ixe4KP7etjYqplIcvxVAjiT0GET6aPaXN8Ub3tKd/OMcvErdRAJyrmxFWVLzOK7GZplO6XuQhFR/pMVTtMkrK2f1axailqNpW6oynqBtYqlAiQmTVOZkjGq0td5hTtEodnPGadLWbsZgiGb0254/RL/nQmY0k4Osdd17iMJ3Ky/WmEmkj48hoUkpCKSsBBPQFsjK4nansTEwEON4YJEKKYrQUeyt/Fhq9JqXYbO6rPleDLB/faJqo1XK2YOLqpx6MRa6AvyNrYmj5JEGBDQC1i5MCKxN7uWs3NEj0KqQM+6X88HdUosu0QsA4zlWPvRIOpDYXFhdV0ZpRallrHxtlYXcmeUUUiQTlp1OHY9IdI8d0syiItsiMgohb8UoRsUTiIduKY5J+WIJJUZae7dw3OU7IpsYNJVEP1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.122561, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 08, 2025 at 07:06:13PM +0000, Lorenzo Stoakes wrote: > On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote: > > On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote: > > > + Kees because this is related to W^X memfd and security. > > > > > > On Fri, Jan 3, 2025 at 7:14 AM Jann Horn wrote: > > > > > > > > On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes > > > > wrote: > > > > > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote: > > > > > > + if (is_exec_sealed(seals)) { > > > > > > > > > > Are we intentionally disallowing a MAP_PRIVATE memfd's mapping's execution? > > > > > I've not tested this scenario so don't know if we somehow disallow this in > > > > > another way but note on write checks we only care about shared mappings. > > > > > > > > > > I mean one could argue that a MAP_PRIVATE situation is the same as copying > > > > > the data into an anon buffer and doing what you want with it, here you > > > > > could argue the same... > > > > > > > > > > So probably we should only care about VM_SHARED? > > > > > > > > FWIW I think it doesn't make sense to distinguish between > > > > shared/private mappings here - in the scenario described in the cover > > > > letter, it wouldn't matter that much to an attacker whether the > > > > mapping is shared or private (as long as the VMA contents haven't been > > > > CoWed already). > > > +1 on this. > > > The concept of blocking this for only shared mapping is questionable. > > > > Right -- why does sharedness matter? It seems more robust to me to not > > create a corner case but rather apply the flag/behavior universally? > > > > I'm struggling to understand what you are protecting against, if I can receive a > buffer '-not executable-'. But then copy it into another buffer I mapped, and > execute it? > > I mean am I missing something? It's very possible :) Jann, how do you see a private mapping being exploited this way? My mental model of the attack depends on a malicious process tricking a victim process -- i.e. setting it executable and then gaining exec control of the victim to point into the buffer. An attack on a private mapping would require a way to trick the process into making the mapping executable (which seems a high barrier) first. > The cost is complexity. And the difference between mappings which are shared and > those which are private and moreso MAP_PRIVATE of an fd are actually quite a lot > internally (go look at anon_vma code if you have the great benefit of not yet > doing so to see the deepest, darkest, 9th circle of complexity hell :>). Ah, okay, I thought it would be pretty "early" in the VMA logic. i.e. asking the question "Can I make this executable?" I was expecting to be common across the VMA regardless of private/shared. I will need to go read the code more carefully. Still, it seems nicer to me if the "can this be made executable in the future" question doesn't matter on sharing, just from a perspective of least surprise. -- Kees Cook