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 2B34BC25B75 for ; Thu, 23 May 2024 16:56:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AE5B6B0089; Thu, 23 May 2024 12:56:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85ED66B008A; Thu, 23 May 2024 12:56:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 708726B008C; Thu, 23 May 2024 12:56:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 50FE26B0089 for ; Thu, 23 May 2024 12:56:33 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C190180644 for ; Thu, 23 May 2024 16:56:32 +0000 (UTC) X-FDA: 82150264224.04.75BE44C Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf25.hostedemail.com (Postfix) with ESMTP id E15F6A000C for ; Thu, 23 May 2024 16:56:30 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qQOktWP1; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716483391; 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=wPAtRznjngEuylGql36bL+F2W4ou0WGvI25eR8lDSc8=; b=RY2bKDQv0Di8DB5d+3vMSwUpu3vkj5cpg8ckSYej9sychxz9QLGyG6AeZRfIUoP99neoxk Oh1FZjoUBIRSDrRxEj9ADYG7eiJuUV21oVT+QvH8mE0Z0rOgwM0DhRaxhJUEdHu+ZqGXOU nwUW6G2b3dZrpo4NRqduxAc7ET9sJGk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qQOktWP1; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716483391; a=rsa-sha256; cv=none; b=NYFcWJS+Gdp7jh4l/lGziAJ9JRBwc6WafzhzFsv0jWjtvQMcL53rxCx8+DR+KFaNOBca0j sQfVZjGr3aVj1yQ1q5jb+3r15KvGdjWnzOjHI/DEIHPrlFHqfSiLA4K/qOGD/aNeMwYCXK 6CrxCfr9IOii47VpqPajfxxFvvye7Ho= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-572f6c56cdaso499a12.0 for ; Thu, 23 May 2024 09:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716483389; x=1717088189; 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=wPAtRznjngEuylGql36bL+F2W4ou0WGvI25eR8lDSc8=; b=qQOktWP1BlfFZ1iG4xYyszl1f3bHV1tzNPuGsKatEpSMvz+GQMFFSRCt17h3ZvqzaM PQXtRmveAG6aJGxuBQaqlCs0ffU1IcLR2S0FMzH/LJ83QAYZ5z4eg2cuabRapASe7RzC y8tJUciSt8Ma9yM41tTvKDWQ8vZCYMRu6fib0STfBCRg5zuWIydo4po4PHguR6gTvfTd 8G/gR2eareGDggTNVO0SFZvrrR1hU9R/EH0QmrgGfRp5vLvXTIv2TZLMrsNFomaw2G/W apOynsW2yflBo9+cGicIgpM1oCRvEbyalDN9DA26fJPbniCWEO//c4THQqHy9WzqMtdt v8YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716483389; x=1717088189; 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=wPAtRznjngEuylGql36bL+F2W4ou0WGvI25eR8lDSc8=; b=El9rMghlmO8Yxa3BdoALQH0IWGEaS2lUqOshCzjCq/Ib/jyEK9D2VX7FUbM/r5Oyph tIpHDnye2BkSQGDNR0iCf5tXJNoPA5zrr81NAxrODRWrs6TE1rEwB6HX1ltzHod/GAxD mqSbor82TM56fG43gkMeKsIzwWYUZIr1z8AlRp8hX0xfq5z3A4M5Qnf6WKkaz8Uy4tHB ig/jesB/6+kTI5HC7aeAlJnR/aDFKJ2kwslDneq4F6DynvSKYENtiKNlIh/x1HtEDrMg OzsEPq/ZE3mR/R0xXHCcungPOsCMHgjTfEX5UeYjzr3SFBNPuW/n3p9pWAlFrD92IQQY cCcA== X-Forwarded-Encrypted: i=1; AJvYcCXYV9tnBuiRzgHOso4cOOm3ALEvd6xtc5dPX+rhSdIjhEX9hjpLkD4pTa+LSBg8BmQA6pDEjXFyysOMJLF0tPCrD4c= X-Gm-Message-State: AOJu0YylBrRmSPWXf2A5hBrCwxLxhrYGMwh33QZn+I/C6u2w4Fs8Rda0 98Bf31T4xKrvrvY67mWFr2z3dQqaJJPs3/rjWOQQu9GTphcmQZ1pacAnw0geRVwT1VicWAGjacz Q3htlSLwtU640hMyBX/rVmEmaXxwVTO2msyYJ X-Google-Smtp-Source: AGHT+IEKxt/I7KxNLtu/2LXDIV7NhlcEwSk7jCcefTmMVoqPfxnhzgRDeNpi0+DdXteBBS3nmRzXpW9VoLpXJ+m+V9I= X-Received: by 2002:a05:6402:5209:b0:576:68c7:f211 with SMTP id 4fb4d7f45d1cf-57843f5afc9mr236334a12.6.1716483389025; Thu, 23 May 2024 09:56:29 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Jeff Xu Date: Thu, 23 May 2024 09:55:49 -0700 Message-ID: Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` To: David Rheinsberg , Aleksa Sarai Cc: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9giding9dsbmbb6of1u7sxo9ac9bm73h X-Rspamd-Queue-Id: E15F6A000C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1716483390-807821 X-HE-Meta: U2FsdGVkX18KTYVHeYffRImvlGCeP52p///DF2rwwXFvUUanVR31/z/m89N2NC1d/JHwZ4AmCHB8562mzaLuqVwNTYgwo5T3y9pBkYXxOGmVX0NcFpOEm5dFyZYS/9xrqK99GZ62V4UCOIpWzhvMD8kk/mFyc+aZt1YtKDmIyR+jwtIH9AB1S4M4WytrDILehlwoX4WH4mY2HI9MqvdZN4vLn1PI6eneJlPVMmWfDNUL7ORd/gSsxh6NruJdW5cMJOMkbY6QGtoQ5rLHMJ01BF4lcn6EeOLXVu5If1UnR1lkMvRpLXVqAC8gyNs67EvswWPdAj4SCm47fxrfEOluD2TLq8/xiBn4irhHrGoVryLRGePCB+nbDMw5r7J6kVZa7JC9NVL6Tpws5yuu7ciOpTmi5rCrGnVHkf8rXFtI5+i1vPbQ4BuXoA+0rzfTaDSOHFgTzHDAcxLQDYCTYrt+TSP8cMjlLl9ldWapYSwf74DEa5C/bOBgWt2WVWmNAepk6zqGUXBNa4XXA7+ehhNTDw0q7XiovaCYZCNJE0LdaS7Ze4XONERF8UhDX4wxC0j4wwXGe9DDW0o2hkjluhYqGUuPdFuwJi2VVF5BoMKfYCUKjE8nTDokmqon1BOpEjo9GeZKAgbu1ihSDYagMU9rNKezAhTluVMJq10l8h6VdyFUl1co9XUq2L0xinl+4qrdTvYTuWx1LwFn2VO7/XCP9Fe9iclV8IVvFOaPt/PsmT6IGyYwtK3wVY9z9ba+0DbmM1Avb+V3UPuaToLo4QRrsI6d/zw8ppdNxem86ptVDjD78OvQotEmsKbPKJ1YyGdF0toerIKLShway7Vet6cayH5u/+yA2sGmaa24DIzcmqxngIXXlDzkrMnOFNpU9dSz6k+pYPoV/qvHLaseZIpw7H7RAD/rkxr8aLNRfmH3d6/IE04YfoOV+VnUKoNanArjrOQF4WsS9DFt0AXrnze n6WfVxtM T3476vDvnczlav6XvQnTsDK/mAFU28fmGVhTOz4Z2PqfZ515oFjj8Rv46F1SRLrXJ5Ysro8SM4M2CpUe0p0KrHZVP0cwPOdpYaIJmbltWxafq+R17biYrD/nwk8uzrjPutNyWrqtZtFlcnHZ/xOdQynttfbs0zOkIt/mRVvz2/v1sgkX4xdOYhliCPM4vRtgLyp+paABx4yEst75HbtnebBdRdCe29mZhwGiJWD7KPEejr0VGCAfEQ9DFwR59mIz+VBms50d0QH3onWoG15Fh0U/5czb1WVlOazDPfjUbczumLHX4CyLrkBloj1wYif04R3w0vBO6XcLik3OCusTc2TT5Y937jdx4A3QN/kIA2mcIqldd8ZB8V83XRBV/BvnJZpEqbyIHWlagzrvv7G2ZENWpOJuQ7oJxbJG3YUhSpPfYMhRij1yjVUXnek7mgxBb5P2BvGsW6Wrb8/y/3f4hR9hZ9xavzB4moHfsMK2hgehr/6JtgK3iN6vIPX7T7SfG5Irciq/eiOsJyQzDjr6+IKH77PE4epYiN2hj+U13MwzzT2k= 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: On Thu, May 23, 2024 at 9:20=E2=80=AFAM 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 Linu= x > > > <6.3, where > > > only `MFD_ALLOW_SEALING` enabled sealing. If a program works correctl= y > > > 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. > > memfd is by default not sealable, and file is by default sealable, right ? that makes the memfd semantics different from other objects in linux. I wonder what is the original reason to have memfd this way? 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. > > 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. > > 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 > > =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. > > 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. > > -Jeff > > > Reviewed-by: David Rheinsberg > > > > Thanks > > David