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 E01EEC25B7A for ; Fri, 24 May 2024 16:12:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 518796B008C; Fri, 24 May 2024 12:12:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C8416B0092; Fri, 24 May 2024 12:12:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 390656B0093; Fri, 24 May 2024 12:12:33 -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 1CBDD6B008C for ; Fri, 24 May 2024 12:12:33 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 91037120CDB for ; Fri, 24 May 2024 16:12:32 +0000 (UTC) X-FDA: 82153782144.16.D7C4D67 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by imf22.hostedemail.com (Postfix) with ESMTP id A84A3C0021 for ; Fri, 24 May 2024 16:12:29 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b=Em9LLFkQ; spf=pass (imf22.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716567150; 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=s+5qKHX2IsWM7J9FUKkWmszqqI4gGvklJbYhyzY7vqE=; b=SHp2F2aOQDcbu6GIHWZ/WKJ3u1EhxmqSvt6nanTClSMlxzCk6aYaN+g+vz5gYd0eJlBB1q N5e+1OP5uph0yapcJUG5PnN+BJW8aAnrDdOnMJusSUPcufIRAwspeA+RETB3TheSvh8hRZ HOz8rv8TNzoPQjj5lwhlfYIqlSSqGBU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716567150; a=rsa-sha256; cv=none; b=JfUaInw9Bj6W0g7y6e5ZhyHaIyqy3U/IpMlEBKrTzI1MFerKHssmfLQZGVMLJzCoaFWMRl sPVWer1Vxm1bMnXOIAKW/Ix2avx9CiYMsAvHbDJMhrNPgxgC/FZKFWtVOFXPPkYP5M+rxt cIBDog4OktsO+rUhPNJ6SutWoOl9DKE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b=Em9LLFkQ; spf=pass (imf22.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4Vm96b4pdgz9snk; Fri, 24 May 2024 18:12:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cyphar.com; s=MBO0001; t=1716567143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s+5qKHX2IsWM7J9FUKkWmszqqI4gGvklJbYhyzY7vqE=; b=Em9LLFkQiu/6zjn522ieKWQ1hrqAxhUL7BmUAJlC1xLxLR78NDZdWzOFQJPTPqWufI0lH4 1a447gcUo4U3LOmz3aZPvN91yOpaBxzJkICnaJ3aojVWRp622POE241XfpZ4znfpWZI6Cn gwCtNKxZBENlEvZXzQZ7qzW9C6m0/Z1EH+G3lJ024fVySHH7/I4kNkMMB80xIsCG7Gfyza q7xEZbwstnrFWuIhNcmboL+pG1+6sFoCX3CZAsItZ3DDPsUc6SjKQ2pQknugrv73UBba5B ZSs4UESPLleQZ9pwqK56V5rKePDs6fY5LRTyFjGCpCXPla95626wOeEiTw+FGA== Date: Fri, 24 May 2024 09:12:14 -0700 From: Aleksa Sarai To: Jeff Xu Cc: David Rheinsberg , =?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` Message-ID: <20240524.160158-custard.odds.smutty.cuff-caukvmB4EWP9@cyphar.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o6rbmbukevbfurx5" Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A84A3C0021 X-Rspam-User: X-Stat-Signature: it3i394q4b9x6z73fmb8rxnbxpxwr7m7 X-HE-Tag: 1716567149-928440 X-HE-Meta: U2FsdGVkX19KMIGQ3L6eIsA7dSmS3sDaTyRgCN2z/r9rJgVv8ziknpkleMtlb2CPMIMGP4wrIwXSPqsCqBIlDILjGNKYEhRMu10vGnXfcJ1VuVDN9YazAor7bcd3vSGoZ/OgPZWNYlRycUmW8npl29Svkc+fkojsSMXZTiqqNWJD1yZR5OdALKYPoj2UBLSIqMMbZV4lioq6WsXkrChw7arSRV2qyohst5YhnPxKQnNp6Kf10tmFPXFixuewctuYaSpyE7vz3TpdDp4tZtGL9RM7QPe526iSDd606GmrfMTa3YAj4m9fkNWBoLgcXq4xHWw3P58sbF0vHbDfv+J9zHL5rUi3v9LcillGww7IUSPewzbj6iQAI7iPyVUqJCCPGoseVlxF6BSkgifE68XIAv0iMJQfjnyM768D/X62IYBsdPvcypp3f7WOD7rqipSv1iy5GvPKlncIhOiAdAx+nIURMKRut81XIAYinTT6Jv8FZR0HC9ee69pKRxiRUL4AqN9nAu5l1y/D6Zxj8bh48qNB97fF6xmRFpREVO2PzPwDAca0bUiYNUCYzVzo80KzU8u0BpJ08UIcPF9nfScXcScA7WcaDtf1p7jW/rpoWxhSiixUyXl+PZQHP9l7r4LshilUqzxOsuNWmiZQdJdV9/a3HFooKFJpbmsS9072/fTkVupMgLNKxGQ/rTJcpcYtMscCyUmtysln6f26B4Dcqlcgcfcn6E8HpNXUTBciGxWZfNPjvlOdt9J9wHNvMJGANhNmNRzc7QN/BXehLS+cGO4faHRi5PeivhJJkyaksBVsYAfw0X//NcPe8bU9Snavs4U22k+ibfp3jUY9Ub4l+AQ5TdlypLaYcmnUFlf5WASh1tB7qb6ZGRoSnYgMprvbQmFtQT1LTflt6GdvC+UdL0trN1oofw9yq0by5MwVnbwACvlxhKUG8XovyQz3rzgDPbzZB9G0IhQOdTutEK8 e5pnIUMe zHXOVdgk+SxP4CoUZfV78bEhJACr3eSSYZTLDa3gecGbm5bEaX2Udid6oRBqVVk+eH+XoH6aK2uaSOzBFgyBOp3Mw0Mk0BGIttwHW/8bof78cHLJnSMhTHgFR/kSADryEhBaFpMY3SFuw4Bys9ALot5pYoxq9rf9Osr8XJyw02GA31aUEZuzIrOOsOfzC1HGj83D5h+jv/mAaCIThs+aaaAPz/1iG4X8axly8ko97rLptUFAbflI8+JnxQ6FQnUui5uXi0PUQf47JNQpbZ/nddSTnTVSuj6akp9XLndrS8C+/8hjP5EsAZpchy3YNbpD+sCctS9Yiixk18jNbr8Tgnx0wSrwPiLkDhL2I4ZLgsjcsocNZm/JMaM7LYA8vTXt+gMDsTuD5FoewkqrpViDR9wuXPZ/wkOn2TXec4+MbhQt7bRr5Ddc0F1zxcWXTBS1B6Wvj3KHwdlcLyblSE/migtqN8iSXRBifkZRzIw6ww3pKJhi9HDhWOmQvga5Cz/hqVP7I9VauxD8f5DY+nwATUANBb4HxlvsZZj0R2I8nL4kjFNrech54oW+wQdB+07f8IGCqdR5fgckN0lqvTl0cieXziMxAW5xFq+YYMNidkqYRa9Gk1tzFkvZJYEx1acwF7FnKHquxZv/WEbM= 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: --o6rbmbukevbfurx5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024-05-23, Jeff Xu wrote: > On Thu, May 23, 2024 at 1:24=E2=80=AFAM David Rheinsberg wrote: > > > > Hi > > > > On Thu, May 23, 2024, at 4:25 AM, Barnab=C3=A1s P=C5=91cze wrote: > > > 2024. m=C3=A1jus 23., cs=C3=BCt=C3=B6rt=C3=B6k 1:23 keltez=C3=A9ssel,= Andrew Morton > > > =C3=ADrta: > > >> It's a change to a userspace API, yes? Please let's have a detailed > > >> description of why this is OK. Why it won't affect any existing use= rs. > > > > > > Yes, it is a uAPI change. To trigger user visible change, a program h= as to > > > > > > - create a memfd > > > - with MFD_NOEXEC_SEAL, > > > - without MFD_ALLOW_SEALING; > > > - try to add seals / check the seals. > > > > > > This change in essence reverts the kernel's behaviour to that of Linux > > > <6.3, where > > > only `MFD_ALLOW_SEALING` enabled sealing. If a program works correctly > > > on those > > > kernels, it will likely work correctly after this change. > > > > > > I have looked through Debian Code Search and GitHub, searching for > > > `MFD_NOEXEC_SEAL`. > > > And I could find only a single breakage that this change would case: > > > dbus-broker > > > has its own memfd_create() wrapper that is aware of this implicit > > > `MFD_ALLOW_SEALING` > > > behaviour[0], and tries to work around it. This workaround will break. > > > Luckily, > > > however, as far as I could tell this only affects the test suite of > > > dbus-broker, > > > not its normal operations, so I believe it should be fine. I have > > > prepared a PR > > > with a fix[1]. > > > > We asked for exactly this fix before, so I very much support this. Our = test-suite in `dbus-broker` merely verifies what the current kernel behavio= r is (just like the kernel selftests). I am certainly ok if the kernel brea= ks it. I will gladly adapt the test-suite. > > > > Previous discussion was in: > > > > [PATCH] memfd: support MFD_NOEXEC alongside MFD_EXEC > > https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahea= d.eu/ > > > > Note that this fix is particularly important in combination with `vm.me= mfd_noexec=3D2`, since this breaks existing user-space by enabling sealing = on all memfds unconditionally. I also encourage backporting to stable kerne= ls. > > > Also with vm.memfd_noexec=3D1. > I think that problem must be addressed either with this patch, or with > a new flag. >=20 > Regarding vm.memfd_noexec, on another topic. > I think in addition to vm.memfd_noexec =3D 1 and 2, there still could > be another state: 3 >=20 > =3D0. Do nothing. > =3D1. This will add MFD_NOEXEC_SEAL if application didn't set EXEC or > MFD_NOEXE_SEAL (to help with the migration) > =3D2: This will reject all calls without MFD_NOEXEC_SEAL (the whole > system doesn't allow executable memfd) > =3D3: Application must set MFD_EXEC or MFD_NOEXEC_SEAL explicitly, or > else it will be rejected. >=20 > 3 is useful because it lets applications choose what to use, and > forces applications to migrate to new semantics (this is what 2 did > before 9876cfe8). > The caveat is 3 is less restrictive than 2, so must document it clearly. As discussed at the time, "you must use this flag" is not a useful setting for a general purpose operating system because it explicitly disables backwards compatibility (breaking any application that was written in the past 10 years!) for no reason other than "new is better". As I suggested when we fixed the semantics of vm.memfd_noexec, if you really want to block a particular flag from not being set, seccomp lets you do this incredibly easily without acting as a footgun for admins. Yes, vm.memfd_noexec can break programs that use executable memfds, but that is the point of the sysctl -- making vm.memfd_noexec break programs that don't use executable memfds (they are only guilty of being written before mid-2023) is not useful. In addition, making 3 less restrictive than 2 would make the original restriction mechanism useless. A malicious process could raise the setting to 3 and disable the "protection" (as discussed before, I really don't understand the threat model here, but making it possible to disable easily is pretty clearly). You could change the policy, but now you're adding more complexity for a feature that IMO doesn't really make sense in the first place. > -Jeff >=20 > > Reviewed-by: David Rheinsberg > > > > Thanks > > David --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --o6rbmbukevbfurx5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQS2TklVsp+j1GPyqQYol/rSt+lEbwUCZlC8XgAKCRAol/rSt+lE b1u8AQCSXfCJULF5mlBI3NTwWtmfPXHkw9y5f+xKfcb1hs0lMgEAnnJpD63h0VKg jcEGjPSfyrhbIP6TbC+mELL+Af3N7Ao= =SpBD -----END PGP SIGNATURE----- --o6rbmbukevbfurx5--