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 58EB7C25B78 for ; Thu, 23 May 2024 02:25:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBF4E6B008A; Wed, 22 May 2024 22:25:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6ECC6B0092; Wed, 22 May 2024 22:25:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5D956B0093; Wed, 22 May 2024 22:25:12 -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 AC8526B008A for ; Wed, 22 May 2024 22:25:12 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4E58F120178 for ; Thu, 23 May 2024 02:25:12 +0000 (UTC) X-FDA: 82148068464.27.EFA28CA Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by imf12.hostedemail.com (Postfix) with ESMTP id 3A3B140022 for ; Thu, 23 May 2024 02:25:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=qr2XdU4C; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (imf12.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=1716431110; 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=a8pilQrg+0LcR8JZ6a5Lw64IT07R5JeNXi2Sc07VtB4=; b=B9smg+AdkW6rVw0QP3m94idIozw3+EKvxnn0lIHmTHTTVihcY9mANLFlQUVpIMWehFrR+9 BGnQkQv7efdcBlAG9A66Fstotol2zYNerpQGrKNLX/8IzBrj4c19r5hj51Rx6Mnn7MyUGT rKsthhJpakUx5woEk2G7rPJe4G+xWcY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716431110; a=rsa-sha256; cv=none; b=jtgxeTDNBzzWOWyxde2XghFMPEIHq+tLdNQ+DZzbXa5+W07eufzoBEDQrxzk7ZT94HbkMT P0XXZVheiMqVLWcC60dxoPbElQvjpa0OJP8e0+ge+zAU4VpBXOnfncpKKxpFEe3pfthe6M OJu7YGeD8eMzrQggstrpZ8BntI2vLHA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=qr2XdU4C; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (imf12.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=1716431108; x=1716690308; bh=a8pilQrg+0LcR8JZ6a5Lw64IT07R5JeNXi2Sc07VtB4=; 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=qr2XdU4CmvcjXQ/Ji5hOJs60iVCpZlR9xiT9We0JAy9Yjj+ax6UIfDjmc5aqdhr64 GcXV8qVxcDNxWVu7WdGC3PYOscTDob5nKQz96ufHTs5TEjs+lWwLnbqm7C09QxOgJT 3qaeiW+IYKWObwAMfHomBt7CzbgN0gkztzQrn2sXK9Osb6sSUA4VPAOjkHo9IYy50n Zz7i0J7hJ8IpzBtkR8E31TpIPqCxfXcDGKvjdv2lYmyMeBLsWc9zErIga3dB3jvyhE XSRL17heXB/dRmFMqsgsK+HoawKRRi27a7b/YT5qvOuOcXPHbXojWMQIFRxV1DXhkZ v18zdL41AXivA== Date: Thu, 23 May 2024 02:25:04 +0000 To: Andrew Morton From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: Jeff Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org, skhan@linuxfoundation.org, keescook@chromium.org Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` Message-ID: <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com> In-Reply-To: <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> References: <20240513191544.94754-1-pobrn@protonmail.com> <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> Feedback-ID: 20568564:user:proton X-Pm-Message-ID: 5f6b9c478d44802fc89ce6227ae33d51f6a60db9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: x8qi6aay89nxa1g11amppu31uxcxfyqm X-Rspamd-Queue-Id: 3A3B140022 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1716431109-939465 X-HE-Meta: U2FsdGVkX1+j3WRzOjQnRZ4MHAuwsvCUHWw89rR92aqHSyRplujzcIqA132TsbcD1RWJsuCPR1YblTu6IHGFKXE5D3Ke0HifC/tkUEF/ULGSy8NCGyRiUZHgfEqgOO81Ylb6w6PRl9g69xGgoLMC2jHb5MmfhZVIydInm8Z20dWvtgFABOKcULkkVf7Oa42+lg1/07UfgnXAZvfOfFjYsDOnRPXsPw8iYB4s1QMlWThk7gstaHvLaxkhkhCJffQRaNF3S6nqyQQ55gfNIgQgo/K22Wv+Cd/cRUrbXBozq5Q/k9cvKb99OJa+x9kV1goPlxDqs00wRneIV2xQxOc/z1aiS/KsB2QFLd6K83zh6p5TLyMLXIKa1ZYKPdv67oGjHfe8LsaPfYelFMwwEuKlqdcYpMy0MZkpyOWUXfORLSDK06MRVf5Ws0klcwwkVjM+ISmctxUpqQaQl0Fu40eFDDQ5PxgzBI28Hgv6BWyOdgmVL4/OOtNOfdG+Tb02UmjtRDV5gKB4T1xqILzyoBOtJeJmsuUqirq74LFArtpQgDoHZqt8EOQVRdF1Hknh27A55VRAQY2e+VjbksoMI9qP36Ey2HAFS1lhJzrp/vr1Bg9TC77arYrOpE5X9zVU4y29SRJo6ZDMWD4vagoQBu0XIiht16DN+6WF7pcAbiQH9mRBKlqqdLE+rPasbg9kHW0bbgck8WJL9LCPQWGOTDNqgrnt+rY1UsYD6ctY2GW5RhwtQTX3VrZf3y0GfU2WzPDWAaSDWPsOKvtAUrXOcx8EqbK+l8d70+zeF8ndl3QV/ONCLCO4+RAxve07e+JT8nELL/8a6FZxyFomaBmL+bwNj8SxWxAKC8/lrAImds9Vde/yTjd0PrIj2czPqWVqq0VtC7sKdgJXfgCu+MyaJlpVB/TpCRHZeMosDrn5D2TcEmr81CL50xiW7OXylohImQEd8Hf4Qc5veqnbfrvGKDK mXIzVhYb 3y4exZsOpc4wP6UZx1Hn500gbPBYQyCqRQgvKqJXKxlzyvvbNU3c1SsnC+2RK0H07JESoRy0Nc5JQ6Ei3Ape1TwAM9WO1jQpJzoTn0khJWfG14Id/MN6DASyldt4irgK55tIQ5qTI3BIzLEK9twcWRRyPAIOgEgvzIcc0Dp5YxNEEnKutZZ2PzYJUMC57p7tQyP+QdQ/UGvPnz19Gu43m7tqvc1zCqBK2N0b1MhUH3d1KH9nlkLxG2qLD0zIc+R3B0KG+4YDT2/Sg9AhGbmEr24wUGxbLe3OcIbvzgEXs1nAiK5NA7D0X7wAh/BEcopNJTVuxFSgRkwUkBWRFiQr8J73tZnjZmeRYn0w5RG4GKJf8Gzi9BqpTe+DvtjYVxLC5Lzzj5QDkPP8xn6LTBPJR3xvF7VbHoMAjp96RXIrhmxzfVLioNRVntZE1NQyv+LhCAiV8NMGAdeazG+G2LEvB/57nF3i00S+oxtGRuh23Ya9MiB9j+D65JPWfprSx1Gtg1XxKieZ61bHdhuvfcpWv4fUYzZCZgFQ6vpUYqZyxOLyNN7aE9BNXB9QCgTPWQyDTVPO4KaHdMRpfndcZpYKJ1V34i1yhYbiJ2GnB 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 23., cs=C3=BCt=C3=B6rt=C3=B6k 1:23 keltez=C3=A9ssel, Andre= w Morton =C3=ADrta: > On Wed, 15 May 2024 23:11:12 -0700 Jeff Xu wrote: >=20 > > On Mon, May 13, 2024 at 12:15=E2=80=AFPM Barnab=C3=A1s P=C5=91cze wrote: > > > > > > `MFD_NOEXEC_SEAL` should remove the executable bits and set > > > `F_SEAL_EXEC` to prevent further modifications to the executable > > > bits as per the comment in the uapi header file: > > > > > > not executable and sealed to prevent changing to executable > > > > > > However, currently, it also unsets `F_SEAL_SEAL`, essentially > > > acting as a superset of `MFD_ALLOW_SEALING`. Nothing implies > > > that it should be so, and indeed up until the second version > > > of the of the patchset[0] that introduced `MFD_EXEC` and > > > `MFD_NOEXEC_SEAL`, `F_SEAL_SEAL` was not removed, however it > > > was changed in the third revision of the patchset[1] without > > > a clear explanation. > > > > > > This behaviour is suprising for application developers, > > > there is no documentation that would reveal that `MFD_NOEXEC_SEAL` > > > has the additional effect of `MFD_ALLOW_SEALING`. > > > > > Ya, I agree that there should be documentation, such as a man page. I w= ill > > work on that. > > > > > So do not remove `F_SEAL_SEAL` when `MFD_NOEXEC_SEAL` is requested. > > > This is technically an ABI break, but it seems very unlikely that an > > > application would depend on this behaviour (unless by accident). > > > > > > [0]: https://lore.kernel.org/lkml/20220805222126.142525-3-jeffxu@goog= le.com/ > > > [1]: https://lore.kernel.org/lkml/20221202013404.163143-3-jeffxu@goog= le.com/ > > > > ... > > > > Reviewed-by: Jeff Xu >=20 > 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 users. Yes, it is a uAPI change. To trigger user visible change, a program has 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 t= hose kernels, it will likely work correctly after this change. I have looked through Debian Code Search and GitHub, searching for `MFD_NOE= XEC_SEAL`. And I could find only a single breakage that this change would case: dbus-b= roker has its own memfd_create() wrapper that is aware of this implicit `MFD_ALLO= W_SEALING` behaviour[0], and tries to work around it. This workaround will break. Luck= ily, however, as far as I could tell this only affects the test suite of dbus-br= oker, not its normal operations, so I believe it should be fine. I have prepared = a PR with a fix[1]. >=20 > Also, please let's give consideration to a -stable backport so that all > kernel versions will eventually behave in the same manner. >=20 >=20 I think that is a good idea, should I resend this with the `Cc: stable@...`= tag or what should I do? Regards, Barnab=C3=A1s P=C5=91cze [0]: https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc76cad7b025bc46f2= 67d4a8784cb/src/util/misc.c#L114 [1]: https://github.com/bus1/dbus-broker/pull/366