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 B82ADC27C44 for ; Wed, 29 May 2024 21:46:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D58F46B0099; Wed, 29 May 2024 17:46:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D084F6B009C; Wed, 29 May 2024 17:46:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF6F86B009D; Wed, 29 May 2024 17:46:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A39726B0099 for ; Wed, 29 May 2024 17:46:28 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4B0484081F for ; Wed, 29 May 2024 21:46:28 +0000 (UTC) X-FDA: 82172767656.24.4EB5B80 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by imf18.hostedemail.com (Postfix) with ESMTP id 6813B1C0002 for ; Wed, 29 May 2024 21:46:26 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=bPj6VEjT; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (imf18.hostedemail.com: domain of pobrn@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=pobrn@protonmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717019186; 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=KZdmKtYJwlym/dE/71cs1Cejh1tSMfTg6pcRpWzcT0k=; b=bj8JglrG3qUuyfoCkTnDCPe27YBKREidLPM3QLBzlDSJCv7flb4aa4LOROXhJ4/M5sUiDW +NuYpFo0FR2x1KINeYD3UPlHs4rNeUQFwWFf6YBKlMa9Exko/RK3exQ9uhuQuTxR8r6tE3 8De80N4lOpWMzqR0YsIxOk57FPBFFbc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717019186; a=rsa-sha256; cv=none; b=V3GOsZlASpiNlj0VcWnO/JQwumvqd6vb0FWqhHENr3ZnMT0CGgcqbR7E7GeFXm4S+KhSyr urB6G2srw2XTFkPxIqQvdIOpCWhGfbtQLwN++zGodBskvk1VyFzbJDxL6jAxTgxBHJ9y9s 2bqRCVaYxAwEdU4tPIGrT7tfPUk0A+E= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=bPj6VEjT; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (imf18.hostedemail.com: domain of pobrn@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=pobrn@protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1717019184; x=1717278384; bh=KZdmKtYJwlym/dE/71cs1Cejh1tSMfTg6pcRpWzcT0k=; 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=bPj6VEjT8xdiArCiKo9on63FwOOGf2RdFRvVjJuA7djaRgo4l8g/l/hlw/BjHplji WSM/1TSls5hw1ApQDTtOOfdZ4GxL+TgnxFqGxBKc3K0jp2dlNYgd1quk9BfuCqwVZk epfx0yWeErkuRRTW4u0ThJU6RmP1iQjlPQWVBwwpYK7SeTdXi315lmBQ7d2aN89QR1 91S3Te9Zld9+h4e35elokPYU/IfeMYGL5GLzt1DMdYpNU5TzzH9qicjyuik9ZNMbpI PIZ9F6Si+ShgTqvsA115LwxyiHAHdU3vltr2TM5X2tQt0mhqmg3+oqwfKm7IqwWRcx +nbCdufmQ8qqw== Date: Wed, 29 May 2024 21:46:19 +0000 To: Jeff Xu From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: David Rheinsberg , Jeff Xu , Andrew Morton , cyphar@cyphar.com, dmitry.torokhov@gmail.com, Daniel Verkamp , hughd@google.com, jorgelo@chromium.org, Kees Cook , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, skhan@linuxfoundation.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] memfd: fix MFD_NOEXEC_SEAL to be non-sealable by default Message-ID: In-Reply-To: References: <20240524033933.135049-1-jeffxu@google.com> <20240524033933.135049-2-jeffxu@google.com> <79b3aa3e-bc70-410e-9646-0b6880a4a74b@app.fastmail.com> Feedback-ID: 20568564:user:proton X-Pm-Message-ID: 713e68629d8783518d3538e80e4bce8eb2fe251c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: o3g9jki4ibkoar34ib3igykkztfodstn X-Rspamd-Queue-Id: 6813B1C0002 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717019186-672884 X-HE-Meta: U2FsdGVkX1/cRwmc2IFy3UZmBGvYNC85ZDfwb0flaOf+ZteahxA65sKYp8xL6WEJVAy0wjW0FDi4xGbUAszBnoPzgvfwxQd2nH2PaxQttoiekqlR1MuBNr21clfMX7aLUpMmLvo7q9NS7T6Ry/ZlHySAZHu2CIi/dyKQ87Q78BVAYrFvNYhEnbJpAAav4qY+j2Gho0Xp+rvcgVyCILNk/U6ajJFGZtKg850asWhzwuGxzH2IviP5RoeFQ0gpvm6IlupTX8Yq2E+K49I2yRFUI28JBwoKI2cVmZNr1gqxTTLvZr1rTFe/APm7neO8+WYIfRvUUV7OpbN8rbtlxcfRQhqzcHjCaR5zwfNxtunwVa6NnOjAXadd3IqftG7gbQuh2wAHdcki3lm5CwhlGMkKXioeX67QNjYDq/Jw5MUoinrxXlmBUOAxWSkhr4OEfDv9tvNd3Sg0Yx/8StadqxDLiGDHbh9ZjhbWG2T1WFVvhCgP7Zn3qxkjwXHRLxupg7xTl7NyP1NJ28IDBMEu8EsIRZsr1ZAyvBaTYlwx96m1IzZFaxxPVatVY2m6TXVRe2wHaZoPhu7tQOtwj5GQVxWdr3Ue7VkvDFrDx7lHdSv7stZMGajrcfn1YEyqj7CXL2VsmMyjdItXVE7tsBySwd9ClMaE+9nVUKoEDFheLMfa2a58fVVdvKcEiwrd5bVG87c8YWr6UW98IQL40l+McfHeE8B5btNYix8rSnkE3xZ5JkPZtB4D3Wdd5J6rX+ga56ykcJbLXE2gy7yd7VAsCgsj63OEyDba3yTDDHJor2rFJRO/zkZVpx5v98tCdLgvyPoFxdvlnrL0v+T/GiyVyDU1xQYsvMRyfG99doELkQ3Y93Z5XX82n9Fr2yT2r6fYyoTHiGD+o59SUr8AasxwBcz9N913muycr1XT0a+bbakad4NZ942zbPYPAnruTtSG0fKBb1rE5BHtTndBazwdBH/ OLWgpag2 DDl1ypVL0D9YWTwRRgUanqGkwmxYAq8wdMpw+tBgCNPg/HXsvUwCe1V2OraFsAWy2z3u9FFivuzJzdHwks35F6AfEIF0tfkm1frhChx5sMrYNV4HrRZy/j1WfArFHF03P3lOLC+1dO+eJ+cabqj14Frna9Msd/3F9elNFfSvzyvvRTbOHnnPGcNjIt7QUvBUhC//0vxn/y6l/tnBYl5b4aIsUfLpMBWG1hP4a4gmt7XybppR2ivckrmpXxoW3VRYPUBBkr3UayXUR640DH16DtxHqF1AMWZQU7yoBy91VBJz11RXX5qw86BXE23W0PDIlbk5lPQskH6DoWQRg8do5JxpmHE6FvhuTkQ9LJmbzoAN55+VkFx5qJUKjMYamUlEfxkgVAAkULggM8PbBMOF4NhxtkFhsIwhTj3rVyTBsWw127tB0hBePLSLlsm7gDvu4ToPIu5kVDB8xrgZXXEzHMRV2w1nzrVxr0lE01Fz1vV2XK0mnWEFKA8HbDJ97ZZPnkuJkDi1omDbnpnii44HDPPrSjckaACL6VUuv/B/FF3QMeg+lfkv2Tl8r861qrMXMy/cWBMAQojX7X85xcNgeZqESDif8PtpF57BLPCvwDEMnRpHXX49aifWJy28ObPt3pvRihfMdBv8adyfd3b+UbYAsNeK/I0rzAmBGzk80/JfggnZRNpeHbFJdGueJprisuLiJ7/ORNX33KEQiuNvHPG9QaBbhbH3jKakPEl1ru79jZM263N4ZjUyGFifRv7BGfLS/sBOpjvMGw5OY/3C68wAKvMI/zjRxx6EidOR2YlI0pF4= 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. m=C3=A1jus 29., szerda 23:30 keltez=C3=A9ssel, Jeff Xu =C3=ADrta: > Hi David and Barnab=C3=A1s >=20 > On Fri, May 24, 2024 at 7:15=E2=80=AFAM David Rheinsberg wrote: > > > > Hi > > > > On Fri, May 24, 2024, at 5:39 AM, jeffxu@chromium.org wrote: > > > From: Jeff Xu > > > > > > By default, memfd_create() creates a non-sealable MFD, unless the > > > MFD_ALLOW_SEALING flag is set. > > > > > > When the MFD_NOEXEC_SEAL flag is initially introduced, the MFD create= d > > > with that flag is sealable, even though MFD_ALLOW_SEALING is not set. > > > This patch changes MFD_NOEXEC_SEAL to be non-sealable by default, > > > unless MFD_ALLOW_SEALING is explicitly set. > > > > > > This is a non-backward compatible change. However, as MFD_NOEXEC_SEAL > > > is new, we expect not many applications will rely on the nature of > > > MFD_NOEXEC_SEAL being sealable. In most cases, the application alread= y > > > sets MFD_ALLOW_SEALING if they need a sealable MFD. > > > > This does not really reflect the effort that went into this. Shouldn't = this be something along the lines of: > > > > This is a non-backward compatible change. However, MFD_NOEXEC_SEAL > > was only recently introduced and a codesearch revealed no breaking > > users apart from dbus-broker unit-tests (which have a patch pending > > and explicitly support this change). > > > Actually, I think we might need to hold on to this change. With debian > code search, I found more codes that already use MFD_NOEXEC_SEAL > without MFD_ALLOW_SEALING. e.g. systemd [1], [2] [3] Yes, I have looked at those as well, and as far as I could tell, they are not affected. Have I missed something? Regards, Barnab=C3=A1s >=20 > I'm not sure if this will break more applications not-knowingly that > have started relying on MFD_NOEXEC_SEAL being sealable. The feature > has been out for more than a year. >=20 > Would you consider my augments in [4] to make MFD to be sealable by defau= lt ? >=20 > At this moment, I'm willing to add a document to clarify that > MFD_NOEXEC_SEAL is sealable by default, and that an app that needs > non-sealable MFD can set SEAL_SEAL. Because both MFD_NOEXEC_SEAL > and vm.memfd_noexec are new, I don't think it breaks the existing > ABI, and vm.memfd_noexec=3D0 is there for backward compatibility > reasons. Besides, I honestly think there is little reason that MFD > needs to be non-sealable by default. There might be few rare cases, > but the majority of apps don't need that. On the flip side, the fact > that MFD is set up to be sealable by default is a nice bonus for an > app - it makes it easier for apps to use the sealing feature. >=20 > What do you think ? >=20 > Thanks > -Jeff >=20 > [1] https://codesearch.debian.net/search?q=3DMFD_NOEXEC_SEAL > [2] https://codesearch.debian.net/show?file=3Dsystemd_256~rc3-5%2Fsrc%2Fh= ome%2Fhomed-home.c&line=3D1274 > [3] https://sources.debian.org/src/elogind/255.5-1debian1/src/shared/seri= alize.c/?hl=3D558#L558 > [4] https://lore.kernel.org/lkml/CALmYWFuPBEM2DE97mQvB2eEgSO9Dvt=3DuO9Oew= MhGfhGCY66Hbw@mail.gmail.com/ >=20 >=20 > > > Additionally, this enhances the useability of pid namespace sysctl > > > vm.memfd_noexec. When vm.memfd_noexec equals 1 or 2, the kernel will > > > add MFD_NOEXEC_SEAL if mfd_create does not specify MFD_EXEC or > > > MFD_NOEXEC_SEAL, and the addition of MFD_NOEXEC_SEAL enables the MFD > > > to be sealable. This means, any application that does not desire this > > > behavior will be unable to utilize vm.memfd_noexec =3D 1 or 2 to > > > migrate/enforce non-executable MFD. This adjustment ensures that > > > applications can anticipate that the sealable characteristic will > > > remain unmodified by vm.memfd_noexec. > > > > > > This patch was initially developed by Barnab=C3=A1s P=C5=91cze, and B= arnab=C3=A1s > > > used Debian Code Search and GitHub to try to find potential breakages > > > and could only find a single one. Dbus-broker's memfd_create() wrappe= r > > > is aware of this implicit `MFD_ALLOW_SEALING` behavior, and tries to > > > work around it [1]. This workaround will break. Luckily, this only > > > affects the test suite, it does not affect > > > the normal operations of dbus-broker. There is a PR with a fix[2]. In > > > addition, David Rheinsberg also raised similar fix in [3] > > > > > > [1]: > > > https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc76cad7b025bc46f= 267d4a8784cb/src/util/misc.c#L114 > > > [2]: https://github.com/bus1/dbus-broker/pull/366 > > > [3]: > > > https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.= eu/ > > > > > > Cc: stable@vger.kernel.org > > > Fixes: 105ff5339f498a ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") > > > Signed-off-by: Barnab=C3=A1s P=C5=91cze > > > Signed-off-by: Jeff Xu > > > Reviewed-by: David Rheinsberg > > > > Looks good! Thanks! > > David >