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 C9805C27C65 for ; Fri, 7 Jun 2024 21:41:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EC596B00A0; Fri, 7 Jun 2024 17:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29B456B00A2; Fri, 7 Jun 2024 17:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18A396B00A5; Fri, 7 Jun 2024 17:41:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F00E66B00A0 for ; Fri, 7 Jun 2024 17:41:58 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6B4D71A07A7 for ; Fri, 7 Jun 2024 21:41:58 +0000 (UTC) X-FDA: 82205415516.14.964AE7D Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by imf18.hostedemail.com (Postfix) with ESMTP id 8BA101C0013 for ; Fri, 7 Jun 2024 21:41:56 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=R5iMop9D; spf=pass (imf18.hostedemail.com: domain of pobrn@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=pobrn@protonmail.com; dmarc=pass (policy=quarantine) header.from=protonmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717796516; 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=XyoIRaw4nzp+JTQlueWeFgCFHVypWtZ2IYQLlnxgLXo=; b=50e5iBRqDCg2xAYPSGMGev3AXJYLDw+yZ55lJxKcoIKHpyDXViSUPpCQqjwDtJ0XQ3g2Mz 0fxsc9T75yqX4QPRe90wdCUrnFqJhIvhurYBl7cdc9sLqq1nGvJNLWB+r2KotNmyL2oU3r 3dc8/dzFxgMWShkO5lwLPhbKuhco2AE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=R5iMop9D; spf=pass (imf18.hostedemail.com: domain of pobrn@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=pobrn@protonmail.com; dmarc=pass (policy=quarantine) header.from=protonmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717796516; a=rsa-sha256; cv=none; b=mRAnqu05EO4YAAyoNhqoOuyW5IMwhQSVYUH0KYLBKlJNkCr9vIeK/SZWGEjoo3SOc5nxiv nZSwCBt3KMxQu9h6Ox1fR6dLDjG8QgOIgg+DCY1+Vl+kr721u22PixgjcHqXYZZ6DXLWtP m0TwILuJ9fy6SeaQTcgrk14T3cDrrh8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1717796514; x=1718055714; bh=XyoIRaw4nzp+JTQlueWeFgCFHVypWtZ2IYQLlnxgLXo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=R5iMop9DHW7Ownvb2JoktckLjiBLCA+aAtm4fsxpZ/bO/K0f4OjumvLQl1n7EcoA7 ahhxO88lOIOqQRJMNnTomfsxxCQs7R+d3PpyGLUF01TgylAOyCgGTvB7IR6vt+RBrW brbknFztOOOPYRR0xxkoO+TUCtodh3Bf0MCk3NO+h5Y/ULlrPYV7vjJHmQKNPBhIrt U+l9HYibXjl0t5ZOPqlPDq46CHUIwtW2aHU5/CoksPmJ1aiLZJ/BbomOkZHMu0h8yi PtViuhLrX0jxnhvvdFW8nfIk49z2RrLIlbb/WFfn8h2DPHK+PZ3f/Qnk/bddQG2mtL U819ZdQNvzspg== Date: Fri, 07 Jun 2024 21:41:51 +0000 To: jeffxu@chromium.org From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: akpm@linux-foundation.org, cyphar@cyphar.com, david@readahead.eu, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jeffxu@google.com, jorgelo@chromium.org, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, skhan@linuxfoundation.org, stable@vger.kernel.org Subject: Re: [PATCH v1 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL Message-ID: In-Reply-To: <20240607203543.2151433-1-jeffxu@google.com> References: <20240607203543.2151433-1-jeffxu@google.com> Feedback-ID: 20568564:user:proton X-Pm-Message-ID: 7824bcd3ec0219abcc9292ba531faca6c127f3cf MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: skyy7yexza5wi9j3xeyywbe1u7cwdkcj X-Rspamd-Queue-Id: 8BA101C0013 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1717796516-741869 X-HE-Meta: U2FsdGVkX1+qjzzXgYM7gGaFfB3OcLVMd9P9dAUXpZlg/6afRtvIQvC8TJY6zD0MPJTOvveJkpkxFGvP5/ostwNQao+RpWBjCMKmLT0NDHBqKYzfT1ddiKR+tTN+xC3WcqsorykiUCL1fs3qujvkeFizEJClsstZmGCaDR1SuBgcRKXie380gboxObZmqZvl0pfCSSvV/BOcTTeRN7Yg0ATQJojJb+uEdsYnhhKwYn+yRyYC7VsbhldXOyZ1yc3r78Qq4TAvJTctAz5UclQV8DQVO9EK7f9nA4bEohWbQiA7UNY4jPtvF0FG5bOvrtVIKAQ9o1X9t+4RtqxjrpUFYMtSpuqwxkm3wFsefIHZtXVMqX1SKqzvcOnSj9+ouLWofxUd+kxCAznxTWOHSXXvw1uNbHBjugBQ8SEmgNW5fHPrV3bJRXeiADgJYK/M6WbuMmlRkmb6J4ZkA5LnxxqdwUB0p2WvZntpKaqvE6JYM22zbSBBHlmadUFPfpgBpIznif7D5uZHVIxeRwzL/vrrThfSqQu/cYeRzKmwmTRrtW2XArtK/c+6lgUvYsVIWNImQ0AcWvGBDmAoj39H+V6va7HuaKnNs+hY0gckD9En935Ldn0+zfiDCZDyhNuHVqnSy2xHb3gRVMopOr7IGn2lC7TWy4x3kHpVjvxfltEtBhcsOYxjfDbGpUGw81LU3bnxXJtD1dPpsV1OEcJ6Nnkfovs3TYF7KyXIl4xKzdcTO7UptJnG5/9MVQft3MukxFlo55avZtjBg4l1anQgj12c1Np5QHdf3EOoyyj7LiWFVSdt4ljHSnPjuUf3X0kQBIoaWgP49dk2BV4pUeZe1kKIeDg9Nx3lOdWQSRLgTIgbtaNN9M0pv2VNIE6VZIHLTB1sSygTaa4ylbkcK7rIEllP4vNvqcGb7CZT9jbvOWfv4JkU1HraIk4vsAPhiKRhE91hz7O8IrgCVtkvgyZ1gfE NY1t1u2m 6SSHjPxCf1K7xkLntFCdoRgLYaP81BzFEEc5A2BtrOgc0+ZKvnnLnPuGABExclRgRY0onmQR3XeEiYzyPE/eHxQ56qf8ycW7Jqbmzi8GP58g3cdrs6OhgizJPBHHuctIGu1KC3F/7GBBSLSVNERRCo1rILO0CmLT82TRKDsyC+FCFhCJNFEEqpFeyngvguybt3xF17G+X0G3RMQScs1pWtiiWeNBA+A+nCIJUxVAbB4iFVlJU7VWPziL+zf75cOHmtA6O8ZcfDU/H4sr+SmPUxunQRIDSag/CQRJwel/1BrAf+Oao2pNfusx1KiG9taT5uu2BzOkg/WsCEYYKZVr7T94B9k97xctw+yObXYkRqh4+rUkQPI4hXS/g0t8DosWKm0cIMLfpM4Ni7THiFElpIbRrXP1uz7Bai0YZODWIaEbkwPwHsCVIaf3ZeaqPXr3H3KVsqLiCmx7+jX/D70ARfCtwfNHAzT/NXh3ouQRPKZCwOsF+rOceUot1ShrNkq8V7hbrY76ayN2q32yP6DpVaWpF5vZK6tWqtxf/54itV051DC4hfBIXRwTBAG2Ob45xA9b2ZdQzuPbvfp6tOnpK44Lxe/vxHKkY47TPaHouwGqyIFHMyn5+ZZDwp9cxBjbPICNY 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 2024. j=C3=BAnius 7., p=C3=A9ntek 22:35 keltez=C3=A9ssel, jeffxu@chromium.o= rg =C3=ADrta: > From: Jeff Xu >=20 > When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it > didn't have proper documentation. This led to a lot of confusion, > especially about whether or not memfd created with the MFD_NOEXEC_SEAL > flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set > MFD_ALLOW_SEALING to be sealable, so it's a fair question. >=20 > As one might have noticed, unlike other flags in memfd_create, > MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea > is to make it easier to use memfd in the most common way, which is > NOEXEC + F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl > vm.noexec to help existing applications move to a more secure way of > using memfd. >=20 > Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless > MFD_ALLOW_SEALING is set, to be consistent with other flags [1] [2], > Those are based on the viewpoint that each flag is an atomic unit, > which is a reasonable assumption. However, MFD_NOEXEC_SEAL was > designed with the intent of promoting the most secure method of using > memfd, therefore a combination of multiple functionalities into one > bit. >=20 > Furthermore, the MFD_NOEXEC_SEAL has been added for more than one > year, and multiple applications and distributions have backported and > utilized it. Altering ABI now presents a degree of risk and may lead > to disruption. I feel compelled to mention again that based on my investigation the risk i= s minimal. Not to mention that it can easily be reverted if need be. In my view, it is better to fix the inconsistency than to document it. I wo= uld argue that "`MFD_ALLOW_SEALING` is needed to enable sealing except that XYZ= " is unintuitive and confusing for a non-significant amount of people. In conclusion, I think it would be unfortunate if the inconsistency was not= fixed and the problem was considered "solved" by a passing mention in the documentati= on. Regards, Barnab=C3=A1s P=C5=91cze >=20 > MFD_NOEXEC_SEAL is a new flag, and applications must change their code > to use it. There is no backward compatibility problem. >=20 > When sysctl vm.noexec =3D=3D 1 or 2, applications that don't set > MFD_NOEXEC_SEAL or MFD_EXEC will get MFD_NOEXEC_SEAL memfd. And > old-application might break, that is by-design, in such a system > vm.noexec =3D 0 shall be used. Also no backward compatibility problem. >=20 > I propose to include this documentation patch to assist in clarifying > the semantics of MFD_NOEXEC_SEAL, thereby preventing any potential > future confusion. >=20 > This patch supersede previous patch which is trying different > direction [3], and please remove [2] from mm-unstable branch when > applying this patch. >=20 > Finally, I would like to express my gratitude to David Rheinsberg and > Barnab=C3=A1s P=C5=91cze for initiating the discussion on the topic of se= alability. >=20 > [1] > https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ >=20 > [2] > https://lore.kernel.org/lkml/20240513191544.94754-1-pobrn@protonmail.com/ >=20 > [3] > https://lore.kernel.org/lkml/20240524033933.135049-1-jeffxu@google.com/ >=20 > Jeff Xu (1): > mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC >=20 > Documentation/userspace-api/index.rst | 1 + > Documentation/userspace-api/mfd_noexec.rst | 86 ++++++++++++++++++++++ > 2 files changed, 87 insertions(+) > create mode 100644 Documentation/userspace-api/mfd_noexec.rst >=20 > -- > 2.45.2.505.gda0bf45e8d-goog >=20 >