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 59398C25B75 for ; Wed, 29 May 2024 21:31:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A64AF6B009A; Wed, 29 May 2024 17:31:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A13CD6B009C; Wed, 29 May 2024 17:31:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DCD16B009D; Wed, 29 May 2024 17:31:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 70BB96B009A for ; Wed, 29 May 2024 17:31:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1950C160245 for ; Wed, 29 May 2024 21:31:24 +0000 (UTC) X-FDA: 82172729688.27.5ACA219 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf16.hostedemail.com (Postfix) with ESMTP id 36801180024 for ; Wed, 29 May 2024 21:31:21 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kjD+YZOJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717018282; 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=FLiA1NhyieWQfcXd3ARNdY+JpVH2itsFMZIhqt+3Mg4=; b=DgDrOzBVdC5a4U/SMsiVFAB1/MnEe2LNfRatd2OAOtE7BHPpi4/OrgrrEjspCRd5ZiF1/J PIepP/VdVEIFoWm1dqttUq9Wyd7UprZVkN5U58TJS8qw+o6qMMKtYgCfsrXnDHKi+y+gEd zVogn2fWeXuFTSE1I7CVl+Y/fmC89yU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kjD+YZOJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717018282; a=rsa-sha256; cv=none; b=So2V1lvDgw1akvJ4et3oQFCgdFJ0thZfOAPktSIwS4ODNUP5e0Ag7ldnhA+7pqECXshIyd Q/Vb0aT9C+wbDxD+PME5CLCN5CgDphXYTtEH01NAVjh88pRFknhy6ndL9/3pw2CRpVgRU8 Qs9ppFQ0TA8pb5p9jsxTk7PQzxnRERY= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-57a16f4b8bfso3991a12.0 for ; Wed, 29 May 2024 14:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717018281; x=1717623081; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FLiA1NhyieWQfcXd3ARNdY+JpVH2itsFMZIhqt+3Mg4=; b=kjD+YZOJsue34rMGEkXcDqUr6hOUmsozbGQWY0xeLJo8P/jmTvX98sU2kJlIOD0Alk JAbGH0p4eMQRNrfPX9hBp6pYaWOKQVQmES1HsG8TQXRfVpw0VNvnCxnugZ+Mf2w8dpSt iZmA5kYcSsiKmvQ9M9TX25WSm13nPTzwXRxUJbtxh8kY/qVuPL3gKVHVr6rvgAuoLwKL 4oqGLAIvDKbQzswLSJB11lUxuovzX4he2+p0Ah5nPuwXIhnaT/SmOBcl78rwGEjxXkjN ohEIHpRKNYy4epy3W2rmDVwsbp97wM71dMufJHOjjxkSAeFKxdaLI4PM0mcQTAF0IpGW qINA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717018281; x=1717623081; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FLiA1NhyieWQfcXd3ARNdY+JpVH2itsFMZIhqt+3Mg4=; b=ZeHpeBU0ukOoUZ28sIm5pGsnFii+4wS86I7obBC5s6ilMnFEuy74mDv22eYpEzJknH SB1H8+4Ps66vLH7pBCSWAqjAy12o76Fr0E3EDuC2AjEFqjewDwMo23Bsf82ZfTQLAcrQ aWYzcPYvjkhn+N51S+UM+8obfd97fmsNKVH8PSgfGNXfIOTsbXmzUd2WrCxn/RYsyXlT XF1rVgwkmd8pGgkU0ZR3VHARTBZ2BP3eF+nhc8WFtXiISeDEb+HEMssVYNH8twv2aJRN IbFOFNBPWtgntX2fx2dvO5mXYXP62LZmktMVbJ5h38LRYPu+rqaGHa0iRJ1BM6X0IBO7 7uRg== X-Forwarded-Encrypted: i=1; AJvYcCU4BcegUHhNHSVjsKphvsj1EE5z3mhRQhPZ05P9ofVMzJb3IWE3kzs7/sA9+BJmEGBsefm99QqXjhvgS6KTj9bUJ8M= X-Gm-Message-State: AOJu0YyiBI4t4vONPfb/QYrjrXmuvy6sWsStN6Md4qI7FbySADBn7l7n uyAJSmIgUZ8FOSFPi+Vr3Zw6jgkKSp8T3+2YU5+N/cvEZrNkSOevJljEFlIMVY3gZfi2HSdg+LR UEynlPQ/pnsQPK6Z3AWwFILVveycy8FC4auhc X-Google-Smtp-Source: AGHT+IE+x8lFbKLlWU1Fq0CgkMn615w4ys1te7GNt5dz/IZuvIoJg4ejLZAvtFf70Zb8LZLZNTajFROLwUn0R5dzS2k= X-Received: by 2002:aa7:c2ce:0:b0:576:b1a9:2960 with SMTP id 4fb4d7f45d1cf-57a18c8ab10mr22904a12.5.1717018280000; Wed, 29 May 2024 14:31:20 -0700 (PDT) MIME-Version: 1.0 References: <20240524033933.135049-1-jeffxu@google.com> <20240524033933.135049-2-jeffxu@google.com> <79b3aa3e-bc70-410e-9646-0b6880a4a74b@app.fastmail.com> In-Reply-To: <79b3aa3e-bc70-410e-9646-0b6880a4a74b@app.fastmail.com> From: Jeff Xu Date: Wed, 29 May 2024 14:30:41 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] memfd: fix MFD_NOEXEC_SEAL to be non-sealable by default To: David Rheinsberg , =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= Cc: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 36801180024 X-Stat-Signature: r7h9t6ethaquou9j9tnzt4mkojcju1ay X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717018281-378872 X-HE-Meta: U2FsdGVkX1/gN6Fthm0QrfAV3sF8WLwGHxUIEpCjX1fe9xrq4YecB8iijlgPrKkggh2ZpeUbZXu92+54+4Z4Oc2oDdwg9MBtjjTV6xIBifK8r55X7DywEYFLloeu5xV/dkIEz04gh+FhymAEIDgHgH0W0TF3MqXESl2IrKN84holo4qfj5MEPlTpAcv0GVMFlYGzbzk6EQ9pKW74qD4CKfLPifCxAp0wuLpzYarm93m0oS2eAlOoyFQtJVGzF858JC8+JNKYwo6tNu0xift5kg7XGasp3WQAlBggZ9ZjFMvoYASwWLQtRCg+tzfupZOLAA5pEB/s88iflTDj13ejn4ijszqK0fbbwxC25Ta8qWkR3A8C4iJ/VbAvQLOrtTU4AForenm3kX5onhCo0qXvcxKowSDNbWpKAsSqjOp61dcl78o8kImkOC7AtPbkSHp3syFMShp2MOCJuVLUJEVteTXq4QuCcSFyVxyvfkcH57PCbgMHfIjfrU7dWOxvBfj1Lkh5VHMRfPl+P+/TTNojKOMTE9EV5DJ5j5+mvNb0wYq7WRiChc6nSQvYJ0mDY0+qiHplk7KE9x4NX46HpJuyNaK+80CrESzNQsjDURKtUQ8iOPS1yU75oEllVk9C1T+Rzc27xGufrTPaOHEvcsXUz/hDWRpvwzTZK1P7P0ZaE8791yB7wILERlDZfsomKLDzZXKw4e/eqi27bNSUmRonhdd1uqH+99pQTv/X3CVD+60zGtyEltY19m+4wfFjwGFBxH+yJeqDgZ3Up6NvgQXvaRz4fCUAm8WzTClfCuTXRTVKZTSUcI75tiSjMtRknOm2zlq4jGV4G1zEmLBvSBE7EgrHJdRByE1kUNeHm8/arfjFx36kN0zdnOtumMNdkoaGZwUDpLcJQxdk5262TC7N/HNt22UGeV3TrAmij1TxTPB+PP3m85y+Bfea4zE+J6YQqU5q5hX10K7wtzR0F5i phiANuOf RE+mBR+OX9MPi6MAtfT0ssE4LFZI3qLKYy+xeHu8DgkspUGHxXKO2eVJdHxOglaEl9UFyM282Mh8pzA81iqaFMObkRvB0oK5+kMYsWNPE+FECfT84cZhnkHMv9ygJjd6Odn3gAPeLyaXClv7doB1K+s1aakcsUxADSABtDJSjY0+qBkskE61Hk6L6ANBi0uxXr/9INzKVHIxRjyFby643PXnFHl01e2215cmOenyVg0hFnwabf/r7g0oofX3wtuGc/KhxsW5pSFL7z/h0H2bOiCDtrTJ2gax2ezYohb6iSGJ5Tf/Y34ClkCk7+mfVBhkaYOCbEtBCPjjyhIGMZNcsytxt1Hau6zvPRKX3TD8kVyo5L21PeA2VSyUEEadmcYOCJLShfV6YlWEFps7uYSov8B9SSmdo5AAFGqNQEX9JKuw+zmxK7uBvTdhmrhtlE+3WzxkVmTXPo3jkYvVeqnQI4Ru6F7xerVVBicSihwLUReRxBYjBdPWSDj1W9wWIefM9SDwNISEDX/jTPii+0rSFYlmIojprNXyIBqF8SINAwLS1/l3P/rFeXnmKjwvTya+i3J2VzTp0EaO7BKWaSWghH+wMIDBv95waQYiaU5NV7iikrIZ7BBPy2SGGbLblA4DAVAuq/3ArlSrBNpF9XjTcKgMkmtv1XRXQXAJTntVGSN8nEdY= 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 David and Barnab=C3=A1s 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 created > > 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 already > > sets MFD_ALLOW_SEALING if they need a sealable MFD. > > This does not really reflect the effort that went into this. Shouldn't th= is 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] 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. Would you consider my augments in [4] to make MFD to be sealable by default= ? 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. What do you think ? Thanks -Jeff [1] https://codesearch.debian.net/search?q=3DMFD_NOEXEC_SEAL [2] https://codesearch.debian.net/show?file=3Dsystemd_256~rc3-5%2Fsrc%2Fhom= e%2Fhomed-home.c&line=3D1274 [3] https://sources.debian.org/src/elogind/255.5-1debian1/src/shared/serial= ize.c/?hl=3D558#L558 [4] https://lore.kernel.org/lkml/CALmYWFuPBEM2DE97mQvB2eEgSO9Dvt=3DuO9OewMh= GfhGCY66Hbw@mail.gmail.com/ > > 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 Bar= nab=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() wrapper > > 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/9eb0b7e5826fc76cad7b025bc46f26= 7d4a8784cb/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