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 52BDFC27C53 for ; Fri, 7 Jun 2024 08:38:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2AA56B00AC; Fri, 7 Jun 2024 04:38:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DAE66B00AD; Fri, 7 Jun 2024 04:38:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87D906B00AE; Fri, 7 Jun 2024 04:38:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 618796B00AC for ; Fri, 7 Jun 2024 04:38:42 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 264B51A176E for ; Fri, 7 Jun 2024 08:38:42 +0000 (UTC) X-FDA: 82203441684.04.E3D3C56 Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com [103.168.172.146]) by imf06.hostedemail.com (Postfix) with ESMTP id CA95918000D for ; Fri, 7 Jun 2024 08:38:39 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=readahead.eu header.s=fm1 header.b=eWbpZLV3; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=RBnpFRu+; spf=pass (imf06.hostedemail.com: domain of david@readahead.eu designates 103.168.172.146 as permitted sender) smtp.mailfrom=david@readahead.eu; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717749520; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lUYVYpbofoM+ovYwmbpHaBkHewk/bAEUDSaoJenkC3c=; b=5/rZugsxlgDjJVUpotc1UxD4Xcyv38fjCKdAULQ/lTdWOUfrk1y7D70FouPCJu762oI1dx ZMe+Btk2lp4nDMT/oBPx1x6psmnM53i9XtoW8XhXiNtGzGnpi8wmNvR6lg/WPaWxLvI4rS GGQiyeHJdiyJVih+syd3LRjXrOsTcPs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717749520; a=rsa-sha256; cv=none; b=3V1bhUfcQOZ19brgatgg8kXjR5oHjlGIvFxhlQjXx3h1xvYsjZRnUBPirPwbCcAl5xadk+ HajZmt+c02EbGifAyatUEWQ7f7CVZ31dBjFdYyb/rkmIL9x5WqZP9pUX+soUjxVv5kImPE MOqWm8/BJWFwVZxUNQwpQx+TglEASaA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=readahead.eu header.s=fm1 header.b=eWbpZLV3; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=RBnpFRu+; spf=pass (imf06.hostedemail.com: domain of david@readahead.eu designates 103.168.172.146 as permitted sender) smtp.mailfrom=david@readahead.eu; dmarc=none Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 05E3313801CE; Fri, 7 Jun 2024 04:38:39 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute6.internal (MEProxy); Fri, 07 Jun 2024 04:38:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readahead.eu; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1717749519; x=1717835919; bh=lUYVYpbofo M+ovYwmbpHaBkHewk/bAEUDSaoJenkC3c=; b=eWbpZLV3ZB2DziJnbmicxBo1Fn JZrGpgbnIrtm6knLo/2K95aw7sfWvJvQgGP+iaSQEBvunGNlUFid+x/+XC27eBw7 KVzBHwzmpl6Re+pC12mGEHfHV67fgQdMI6xpWsy6uTafJMCUdFqdkpoj/Z7vZTnO n69ztEXXTflrkhtm1rCxG68hoZn7n8hD/lRpfarPR6yrp5GQEKFIL8STPXfZAxqq dwvrWHBVzqo6NmAXKcPjcmk3DwvG2ZSdpyrtS1tWW63QSZDvd4B8F6Ez2cFQNYDt Pa/iSjsFkBM3+Zk0PAuqQatt3WyHDgiQuz1OfiSSIsmEuDdTN3F0oeNtJRwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1717749519; x=1717835919; bh=lUYVYpbofoM+ovYwmbpHaBkHewk/ bAEUDSaoJenkC3c=; b=RBnpFRu+ihHlemOYuCsaIVAoRXtslx3w/Xv1Rb2b7ygk H9noCMD/IPpKWYSDaIhpMuvHqvXJp54Ej150F2uduU9nojT+PevNV2Mo23cL55y3 Ww+1AUwe76f9uTAqrQMRJJxkN+zg4NaGKogzON8FdP+O9RAfPJ/t4BeKH2t70+Xo x54OKvvLkz4MJwBOpeGlxsolf5TV5zDys8ln431v6DL04fXExbhlg9ysIOvozdTe wv+ZV8App3v+1GHxNHIUmRUKPrYnXc3CBx4cAfmNoOkiwOsCL8CIPE8FMhCrV6BT LoRqJ0NWSVBu/AnssZTDgmD53mTs7P0bKfK2OD7Blw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedttddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfffgr vhhiugcutfhhvghinhhssggvrhhgfdcuoegurghvihgusehrvggruggrhhgvrggurdgvuh eqnecuggftrfgrthhtvghrnhepfeelgeeuheeihfeuleefleehtdektdeihffguddvheef iefhveelhedvvdfhueeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepuggrvhhiugesrhgvrggurghhvggrugdrvghu X-ME-Proxy: Feedback-ID: id2994666:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30DF01700093; Fri, 7 Jun 2024 04:38:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844 MIME-Version: 1.0 Message-Id: <1e1edbdc-f91f-4106-baa6-b765b78e6abc@app.fastmail.com> In-Reply-To: References: <20240513191544.94754-1-pobrn@protonmail.com> <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com> <08450f80-4c33-40db-886f-fee18e531545@app.fastmail.com> Date: Fri, 07 Jun 2024 10:38:16 +0200 From: "David Rheinsberg" To: "Jeff Xu" , "Jeff Xu" Cc: "Aleksa Sarai" , =?UTF-8?Q?Barnab=C3=A1s_P=C5=91cze?= , "Andrew Morton" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, dmitry.torokhov@gmail.com, "Daniel Verkamp" , hughd@google.com, jorgelo@chromium.org, skhan@linuxfoundation.org, "Kees Cook" Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` Content-Type: text/plain X-Rspam-User: X-Stat-Signature: qdewubnf9xxx1aew4c7rrzccehewku6b X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CA95918000D X-HE-Tag: 1717749519-952171 X-HE-Meta: U2FsdGVkX1+irysbD887m+4h9FYBAX3OnM2ZbDUFN3B0Z28uJRwNbKJmDpeLV2U2gwNHs0YIHPR7x6nR5yJV0HKnpP6Ehavwjafh7wlcWL2h6k744ZAXK3qIkUpW086k08HYOAk7eLHebQXHu/3/oFCJie3NwubU1CNzMgsBuhXbj2lpENnq+k3EOJiQMZcs1s3y+2zakzTzF7JLFnRI7INYB+fpLJ10rkIo70VczkQKrB+zctCiR5ijqlNLLptthHVc5EiVUDbP8xsOL93GLC9Qr0pTm3JVmGweI6ljMM9LOahZY9bU2elC7r6C3XvuyCsLMC2ZjykgiuHjVbm5u70aBUnvUdTX2SqhXH5NX7He76XYRXuE0cwpHB+FzJeD7SFPk6vZ43kPxs67gXyOuJ+shI0d8xlGxBTBeSWHwsA0mLk2d7oPGi2E63WfrEl5j9U8fvhJsgnHqQFi7mDuhH8V9hKXB04XjMG+DoMHsQ5rcdhtobOtkrD3LBFzGo4hw/d5UQf1R6pQZmxfLGRANaPjUYbJgl9VqVZE76QM5pSRRJxto0OcaAQPV4AS5d8QE4dXJVs7FMtldi8ElVPcsnlLlniUWLhHyyy69gKYku9KeF06l4zPxLLMDaUaduxdwR4J8vjVL9J5E+IcIKLZF6szw8NNiMT0SuMlZ8zk0WK22qP5/R1sAthG710l+AyqnmeCJ0UJPTLRGUja9k1mdVq+l0NSr6dlbtTFzU3ebgptZyCi6hviOewwuWbINLwQT8tWJdN9ioqbl4wcFKIz2YCJlwMieawyQiEelfzNQQyzuqXwbCV0r3Rq+/lft7Dk2ZKEaGAIp8mZ/sJW1xLGA/7MBXYZkUInJcOPNmiXHs37hAKthS4ibUY1ZIwnRv9zN0ySjwHZcSwAfv8wjsM8wgflUColzqOB04KVBNTy5Fd/ky2zp+V2wEDwUjYhqKJ2cDh/IYTXg/TDVKbHWgN 9unSsloR d7tOaOQ4SLQBxnedSeOgUlDpKix9R5VFeywA0QAUus0PezGCxUG/6lngaw4eyHdwYAPmCTPz8g3199dUklE90mXeaJ5rF4TBsXGPIzfmGOMeJt2GuZh2lnA9//bb3PCe5yljg+6Q9KVr3D1pJTxQyzPtChC8T+QTFUlwEHx/O3bHjtgHvUSdrpmORjUMhIVrOGv1dnuK72yHvUHC6LYLg5PbgqmlUjMpDeItmqnmAAY6htIOr563Fe/hsUg== 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: List-Subscribe: List-Unsubscribe: Hi On Tue, May 28, 2024, at 7:13 PM, Jeff Xu wrote: >> > Another solution is to change memfd to be by-default sealable, >> > although that will be an api change, but what side effect will it be >> > ? >> > If we are worried about the memfd being sealed by an attacker, the >> > malicious code could also overwrite the content since memfd is not >> > sealed. >> >> You cannot change the default-seals retrospectively. There are existing shmem-users that share file-descriptors and *expect* the other party to be able to override data, but do *not* expect the other party to be able to apply seals. Note that these models explicitly *want* shared, writable access to the buffer (e.g., render-client shares a buffer with the display server for scanout), so just because you can *write* to a shmem-file does not mean that sharing is unsafe (e.g., using SIGBUS+mmap can safely deal with page-faults). >> > If the other party is controlled by an attacker, the attacker can > write garbage to the shm-file/memfd, that is already the end of the > game, at that point, sealing is no longer a concern, right? No. If a graphics client shares a buffer with a graphics server, the client is free to write garbage into the buffer. This is not unsafe. The graphics server will display whatever the client writes into the buffer. This is completely safe, without sealing and with a writable buffer. > If the threat-model is preventing attacker on the other side to write > the garbage data, then F_SEAL_WRITE|F_SEAL_SHRINK|F_SEAL_GROW can be > applied, in that case, default-sealable seems preferable because of > less code change. Again, the threat-model is *NOT* concerned with writes. Graphics clients/servers are a good example where *ANY* data is valid and can be processed by the privileged server. Hence, *ANY* writes are allowed and safe. No need for any seals. Those setups existed way before `memfd_create` was added (including seals). However, when windows are resized, graphic buffers need to be resized as well. In those setups, the graphics server might call `ftruncate(2)`. If you suddenly make shmem-files sealable by default, a client can set `F_SEAL_SHRINK/GROW` and the privileged graphics server will get an error from `ftruncate(2)`, which it might not be able to handle, as it correctly never expected this to happen. Thanks David