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 21FF2C25B75 for ; Wed, 29 May 2024 22:24:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99FBD6B00A4; Wed, 29 May 2024 18:24:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94FEC6B00A6; Wed, 29 May 2024 18:24:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 816B06B00A7; Wed, 29 May 2024 18:24:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 64DF36B00A4 for ; Wed, 29 May 2024 18:24:58 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2590C809E5 for ; Wed, 29 May 2024 22:24:58 +0000 (UTC) X-FDA: 82172864676.02.81A2F25 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf30.hostedemail.com (Postfix) with ESMTP id 4CFA580008 for ; Wed, 29 May 2024 22:24:56 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IiaPeh5Z; spf=pass (imf30.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=1717021496; 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=vmgn0iguBHzjec86+QBU6BresH5wuUbRjs/56VQrvfE=; b=SHGdNJq4Rasket2XFcf17r+zplAouXJEla2n3L5OXp4TT5zjqCOnv4d3wSRLSNYF1U+ZaG s4kiuzER6eNznySpnF+sGV9MIu/8Rf4K9nvqEXuHMM+X0BC4K17bPmTXaGMRVeFcFG8Zto F2iqrdeo0C2SWlX2bnXRt4uee+LKQWA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717021496; a=rsa-sha256; cv=none; b=4PYjoXkfjzMAdRfihMdYIzd76FJi2QaXI1McoaeUdZkAMx0R2Vdj+78L8f7W8vEgY8Cr1g +ePmijyWrrGb2yf8t9TA30C3mUIG2hI/Vs1dMf7oAo8cbBSy1jetx9Qjp9mHLfJxNr7Wty gtV4mNJR2N1MDLYmifjb1KpM3ycHZhM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IiaPeh5Z; spf=pass (imf30.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 Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-57863da0ac8so1766a12.1 for ; Wed, 29 May 2024 15:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717021495; x=1717626295; 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=vmgn0iguBHzjec86+QBU6BresH5wuUbRjs/56VQrvfE=; b=IiaPeh5Z/BmN/qFXX5zTb92C0cfRV/vP+1OFf4YTbMb2OWfKAgduUYJ87XbMng6c7s AnEf1hDUU+dehcu1adtn1MkK9YTohSveES4Ai6jXyTEdBkyJ0xCjUT3ryFBgHgQgqRRt vtqoLiwht+K/GqujWgzHB6HgtZsK96FGt/zoACvC+DVKfqN5Jim5kW1RhP+vPOTLZzn6 ZGrqnsEx6Izxax4hW6MNrE8v0pstrtR/GeetUk8Z/E6wpmN2w+JS8KohdOisBy9qighV XS2leGcB2z4HMyuoU+DhqtNSMBFCBiWaDdhJwwP+EVed96e23QKsIf78ZLIiwX5qZstK 3rTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717021495; x=1717626295; 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=vmgn0iguBHzjec86+QBU6BresH5wuUbRjs/56VQrvfE=; b=J41LqBx4r12RawaDVf7TGIqdeb6OsWT1XBQXt8yoad0dkwcOOEr+6HodrRNaeGs5bl lRS1SQvqhaw5j2bsj60hOqf4lYkU4vQ7u1EmlCVMYbjEdJnwNKLFGWqN5NLSTfIpxt4o oLsVF9PpWGMB2z7keedQ+GAAxZmYTQXIlWqLvbMkWOx9e+8fgpn9T1NWnvT6uw2T3GIJ Mfv+4hw8YlPiqii9mBCtVfWBL7B4SwG1VJ8Gwh89wFSRu7NdhRNAL+bS94sipqFWOjKL KlzJbuCH/QxaJb3rYdTlm+FJH1xpfeZAY6VzxErxNZkhZGmIvx+OWRQJoqXhiqPNTIv2 J2oA== X-Forwarded-Encrypted: i=1; AJvYcCVkVgtc/DW5NHa7Rih2X3+6f1J444hareEXZOFneT/4n7zhpKTLjyshOETeVwaCmAPXgndQSGX+Ye59QvUhWbfgDlE= X-Gm-Message-State: AOJu0YwMfOAyKMM+7o7k/rPL4AaV+HqXLNbumkQmReiIqKXCWh+Av7Dx ZP1ZLrJj2yle6z+xKoXdnWAMl+pGHaIZfwzlxasb3z79om1mq8gMayx20Gt6fx5aU+Tc8x4wblo V5UBJ/VqJaLF7vIXtXYUsNJxyIvM7TKF8JDWtt2m7Tp8OLSONuGyN X-Google-Smtp-Source: AGHT+IHkkh9x06qFU9ZLKk1fSNy1UgCz5Aewkn3gIQT7QDAopstbEwZwp0LySpOiKlbZGOlCiquPRCB7g2nzucbt4so= X-Received: by 2002:a05:6402:174d:b0:578:5f77:1e77 with SMTP id 4fb4d7f45d1cf-57a1625924dmr72973a12.0.1717021494478; Wed, 29 May 2024 15:24:54 -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: From: Jeff Xu Date: Wed, 29 May 2024 15:24:16 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] memfd: fix MFD_NOEXEC_SEAL to be non-sealable by default To: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: rep4j5xexpnidekr7n3f15833z8kjspm X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4CFA580008 X-HE-Tag: 1717021496-594059 X-HE-Meta: U2FsdGVkX1+bm/Ow4Qkc0w35YUHRcULYdlm20/g9CVxc19atLd4FE9hZmI7JT1ngiSTUrN4hb6rZkQQnTGsVnii8p5kpwoagYd11tH1jAh+WSP04/zOWPmb9g1BuDgx0a79uZazqEK7vvFHymQ2dSSxJJzU3hyMm+wr0S+s1huY6J43HusKUzsS+VQMqTI8Zpp318WlEeTitJvXKzOuiQiOEd7bw43I3kCNbziLjQvvkmiZ6eCx8c1pZ29WMWkuv5XtNqjLsgzO5I+l+2wB6K04OOKxSudE0HTlO2AoYW+SACN1+AlDdClo6YZ64F1U7aF7P5Rvf1tsYek4qSeLc++VFVf25k4z7dtFSdkrrG/P5PGxHp48j2rr4h0KFbT11/iVcApa/miyeAyFXZpV0eHQC2Sz5lJtHa3wala5ZGdrBJM+pCJcNe1Thq4B2NwMussuT64TSTaaHiwG+NFNqM+zcyKhcIxFxBiJmCYDf2+ty/DlhxN9scLaN/Snehczmq0yPt9EYK26aPYaNtOaRJqA42SEAbS9oEp13+WKV26AlNEuS9Pt9XNXBUDXaJfZFRTDC/KGapJWZhmC7vYML1bWqpbZ0dzixzF7RdnXzo/8fS3pZkSjyMJKZTumyr8vHc0I9N+5Sin3fEC0ru87g2FPZK+wWcOnhfbzIpBx2Zj7Oihx6fT5MQdHgJyGzNL7oh8vpHwNfWqYNspiOX8v0rMHtY+lEytKSKBQ7qMy2fcbbmFfv+o6bcvOsUJiuKJOoBSNQdyHCVspQ2GDn4ZN9PDz5oJK447fhTV1LA4H/zHaXPIjJIcshGxq+U8nUbd8E/7GtfjH7Jl3qsawMrfZaQLGku72bY7Yd0P6s3N6KS3TgNShBoHitGZmI/7avTi/7ovhY7TnuUqEP+sKw6FFJiOed2W+OqjZ9KEYAWfbovAv2ezDyLy4PF/VTdmEzIm1Vqo8XSLhq9b0KyiN3Ygt UZ5Lh3Be mzm2bMSLHrNAILbq1SfRwo1aywkWngsYfB/QOQe/EFAuP4FxuBc0M7AnguMyKrJFlfpKXfWk44Xc1cnR6BCnu8ZLSNYA/Jq3XEbM5npThJC2WwMpKmYZSv1vmus3bJcdxSKkZJUbU2AuSso4IOAHm3Qq3xo5qSFIF/j1mId3oYT/yz6XHDSPthHA6acATY4tLIngL43tlmFxBLDbcskrSd6HO1Y547/28mt7nLX33Ca2R5Oc7p6K+rKOIj7Pvbf2qOtj0mmXq0uX0saxN5xESI7kXoYLtMJN0AJ0IG4+4ElA3kMnJ2V4vlbxLlO30QQqvQ80uCNqtisf51iKbamxQxZpXtaDHmGMazfGakzTOOluDPoZWtRGsVmVwN29hIreMaLCD+0ML3ivSUw1bnF589Fx+iyFsttlrlaYn7ayMYaOsa3MUWC/ndV5grtGHL4H/awOgScTRRltccPkgAlulGprqbk4Fng46EQcxRqFJYXY9v0NRUA58XKn8Qvo1eJW3M8hjGX0vpG+bL8Ixm7TjTNyg3NiZ25oJ74lnQvq2BoUBFFnTrI2p/P+JoLVJTO5CoyZj7iOqwIzqM5XpU3wbdY3xdNfCLvqLyUwoFQCS3MfP7wG8mtv+wtaexLP34i8f5p2PsvGsqwQ8UFD5NoKn/4jQ1QcMBVT8ggCaWfT+Q+M0pUPoiDrK3gWvuF8VWl4Oiou4hdTbtdFSPNHSccrfO1IrI0ZczZdAPVOfB6k4cpD3WvgOVerBtnmLBDLCl5N4C9/9WDcX5/zkPho= 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 Wed, May 29, 2024 at 2:46=E2=80=AFPM Barnab=C3=A1s P=C5=91cze wrote: > > Hi > > > 2024. m=C3=A1jus 29., szerda 23:30 keltez=C3=A9ssel, Jeff Xu =C3=ADrta: > > > 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 crea= ted > > > > with that flag is sealable, even though MFD_ALLOW_SEALING is not se= t. > > > > 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_SE= AL > > > > is new, we expect not many applications will rely on the nature of > > > > MFD_NOEXEC_SEAL being sealable. In most cases, the application alre= ady > > > > 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_SEA= L > > > was only recently introduced and a codesearch revealed no breakin= g > > > users apart from dbus-broker unit-tests (which have a patch pendi= ng > > > 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? > In the example, the MFD was created then passed into somewhere else (safe_fork_full, open_serialization_fd, etc.), the scope and usage of mfd isn't that clear to me, you might have checked all the user cases. In addition, MFD_NOEXEC_SEAL exists in libc and rust and go lib. I don't know if debian code search is sufficient to cover enough apps . There is a certain risk. Fundamentally, I'm not convinced that making MFD default-non-sealable has meaningful benefit, especially when MFD_NOEXEC_SEAL is new. > > Regards, > Barnab=C3=A1s > > > > > > 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 def= ault ? > > > > 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%2= Fhome%2Fhomed-home.c&line=3D1274 > > [3] https://sources.debian.org/src/elogind/255.5-1debian1/src/shared/se= rialize.c/?hl=3D558#L558 > > [4] https://lore.kernel.org/lkml/CALmYWFuPBEM2DE97mQvB2eEgSO9Dvt=3DuO9O= ewMhGfhGCY66Hbw@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 wil= l > > > > 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 MF= D > > > > to be sealable. This means, any application that does not desire th= is > > > > 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= Barnab=C3=A1s > > > > used Debian Code Search and GitHub to try to find potential breakag= es > > > > and could only find a single one. Dbus-broker's memfd_create() wrap= per > > > > is aware of this implicit `MFD_ALLOW_SEALING` behavior, and tries t= o > > > > 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/9eb0b7e5826fc76cad7b025bc4= 6f267d4a8784cb/src/util/misc.c#L114 > > > > [2]: https://github.com/bus1/dbus-broker/pull/366 > > > > [3]: > > > > https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahea= d.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 > >