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 662BFC25B78 for ; Thu, 23 May 2024 02:40:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB7CC6B0096; Wed, 22 May 2024 22:40:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E41E26B009A; Wed, 22 May 2024 22:40:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE1B26B009C; Wed, 22 May 2024 22:40:56 -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 AD5EB6B0096 for ; Wed, 22 May 2024 22:40:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5C4291C02C9 for ; Thu, 23 May 2024 02:40:56 +0000 (UTC) X-FDA: 82148108112.16.EF19852 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf04.hostedemail.com (Postfix) with ESMTP id 7C3B140007 for ; Thu, 23 May 2024 02:40:54 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="cBj3Z/jV"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.49 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=1716432054; 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=jWPP+Dz40GrCKZ1VUrua2jxqIySm9s34x1EAA+mtGnY=; b=YmDltsYzCHs2cpozN+48Uc7au/uQInMGIbtc4hi/NwWYqrTNHgmCEQmw2sVX3tDpe5RFzN GCJRoO+vu+gbzxVQMcEp7doq2XNSLWB/hUQXjfTK3KP1oafWynAMmypzh5Stan645kHpAf S9n2gZgcaES//eWnqbvwRDgiXeuZOlE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="cBj3Z/jV"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716432054; a=rsa-sha256; cv=none; b=782Z4O4KvxnMcQOX59RDfQJ8DyEFG3+Qfun4R61gX7vQsk3JDdfmvBuwYHTC1lvlzviKEK nkiZ1EGnYVyq7JIoLujsuCa+xGnZEKRoUOidS5hpPDCuP7LUi2Xqgft7DK7Vz+sArxyJFn gHZNdYXmfXg1MgAf/G3FX9VWCBEjees= Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-572a1b3d6baso4681a12.1 for ; Wed, 22 May 2024 19:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716432053; x=1717036853; 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=jWPP+Dz40GrCKZ1VUrua2jxqIySm9s34x1EAA+mtGnY=; b=cBj3Z/jV09YanP+lHlAPnLLnTHBfJ18HOAHoksViIUx5CDpNkG2RCqGcgx30LxqZpH OzDUhYqI1CNFfiwiWPV0tQAOLx3pSThiEK3DgVnoOC9Y6z9gTqYzcHIghKFWbhr2OxF5 CyOyf3UyRQAFP462u/412zZxc6IKQKv71mhbVZn8zojWxAjfRPSKn1wlo5lobQSwATz7 3RaugVvdh5B4T/viAh5ZmU6/2h/2AMBcfN1AgOkyOUwxYR76tcEEuhRRtM0jTuZ8bpdD ZXNm+klOiB2jC+THWhCoCWSgAJH3rs/yR8pO5vEpdIKLzMyf4bc97exR5J0y4Legdkwp 6DIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716432053; x=1717036853; 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=jWPP+Dz40GrCKZ1VUrua2jxqIySm9s34x1EAA+mtGnY=; b=hmAZvHxzSqP/Vak9ck7bNzqo9lc5JV/2y+wrVVQ1TpdmNY1b3pLE7tYWBDMdQRCQoo yT7YANVhCtKrqHhXXeT5iEorQ7FN175QT6W42Icgj5cKCMvK0/oA07AJkph1sT1pqgTW 9JpgItmL0bTW3HP4WQ1G9GfMu4WE6+DFii7u9+FfOhPwFn61beSPocN6/uQyNb2zrdBc nCwTxRpjdx2uzCe9B/lRuwxnzMBOX4pJqXpHx+FWMUgi4niUyXNLyXx+JEf45aSf0DTH kgo5I8WcSGkzcKfk7xkvYLRcvL9uoiDcK0MXywgaIWL5nlXCPVmAsH53W7tm004cNohl rkWw== X-Forwarded-Encrypted: i=1; AJvYcCU3p+gS3peGtkmYZnVF8Tf0coU0+pttalB9XfCN15pzUi2ooAoFW4LAqwctH3oKfKRu8VzxxhOA67KD54ZQZWpGsTY= X-Gm-Message-State: AOJu0Yzg4PX31DyEHEZGOI+e5jUKN58XXgEjNyMTnCeI2F1BjIFxalsW QbLY94+QqTZskQQMCywhix2ESbCERRtkFgUqxgaQMDSwAOGvxKkRhjjXDdirs2hlyPaIbexD+4x oaFOIh+dsDd/db8+XVogDX14F2XSc/0rs7EjZ X-Google-Smtp-Source: AGHT+IFoMprtUuWbtKldBe/3g28FFO7W6k7ncLpONbXIhGG03bnXo2gGbai+JCKMqKm0XjcPlnfIbbiQJUoxfs57HHY= X-Received: by 2002:a05:6402:4305:b0:572:9eec:774f with SMTP id 4fb4d7f45d1cf-57843b1aebbmr108042a12.0.1716432052838; Wed, 22 May 2024 19:40:52 -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> In-Reply-To: <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com> From: Jeff Xu Date: Wed, 22 May 2024 19:40:15 -0700 Message-ID: Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` To: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= Cc: Andrew Morton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7C3B140007 X-Stat-Signature: yr9bffpu97mooyohu6a4nk4qoukwozzk X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1716432054-999803 X-HE-Meta: U2FsdGVkX19p1U2hbPIeQagGBmerLp0/R8lcPHNa4MZ5Y9UHA98yDBfen+RrrUTsbTJlRKxhFXYDWuf1917Wfngiu8LiZbyY/NsHcmsWdbjv9/fD8ERo8ztC4vxpWhSYvAGc2lb/7AzeYCAHCexvyvqhJGi1R9vdfN9yjyG9ilbldm+QLGKnLS73aArGObkoIk/ioJw5/8tvcx6K3E3GSWOOkzMVFXB7wpB+If0I26KOS6OevZfknrNJcPn4zlpLCoxarIAifMchuoJeYs6A88eiisZ4wQg1CjidnNFIFGGM87krlTKDB8SjaDketb0k14nFl/rYdZdI9QLxmCNC+fRBt0IX67iQ6PAk/Sy4jGrgojKg/I69SfQMwdVWi553LYeKnCxLl78H2fVfbc84tsWZZZemWj70TBTcjd64bTxLg+FiHKQ0nS/NdROcnPlumZZffnVfeBTN+GO4qYzlS9Iy5k54RrHi5x+Pz+28hy+WJ6UNP8+JjWVd06Dj1pt0cc8pIicNvNWTyVJAetktg39p0FliZjMwBg9DeaTs8i08iKYDiYek+IkuD1lP4R3CCsvkqJ07dWv+MhtBm6IcpUqXOn0u+4rmpRNxtEJ/KEPFFaKjKs+TiaMHhcZF90BNk3qYrsgKpGYBmz3DxW44iqKLaneIMnRk19VvrApnoqdnTC1AAAJefKu/rTN6iDL69KdAAtIVzfu9oLCX1YS30yA3lN9HpKFV3Es0ZbZ2q+VhVjDEq6XPxm2iTvqGw3NN+n9gwCtzmrH4Lc9QSoPwo06MMc/Cvkq0xaVpQiNE8svMV5YAlu2hc2OHsASRs7sFlacenE+kMEPHFdEPM41dZJ/sr5AXgLeFE+Hq8zcZwFcwLWj1VD+QoU9csA/m0jw6mPKX+0zl7xF1kvtAvnPl4GClQC5VtDOqAzyirWErafMO2k/apAdToIgwlUTuiAWKLizV/Ghy4NC5RpDlTgR ACqYCKn0 /nG+eiI904aYHzAw/kYzadV9EBbru9gvTsq1cN+1Irbn7I2GaudotMzLV3YdAzlwVA56olDvd5DTRx17kbTrfun4N1TK31HGEpuXaaqT6Z9Uhn2VH/FBD3DhmN8P/spP3FLiup7v9uP6XXspLm22c7HQNq0JOU28NHXB7sXgFyt+ZBCCz7fsgS5ZC/Lk/C2CN7eMSzM3xPxTwkRsnX++mz4iNORuQpkKBLRZPIET31VW6B65wtQCwJNw5ujUECdF5bHy6R5F1szhkFfYAeipo2xXkySZ7WrTHzsysYZYZ/0WWOxWblYlQE1TutWn6S732iN4QcQ2ymOLbstbqXjh87DAvJkgzmNjCygC84MxWRp/uS3uYS0BJSqVeXoWbSoxZx769u5QJx1NVq0FEIS1vX7vr6eJbdexiHiN2AsxlXQMq8iZ3HbZaDUQNiVy1fvqnw2WZu+WX+fvp2RclJ0MHeY2xxyvzg6/GwtDSMmLByyCVkBhUx4pIYVsYWJr9VwfzuRQS1raivYdirsg2SJYwUAadC1QqMhUS2nIMJLfUfbotTCmFPeSd9xfs7lQY8QCR4jg7 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 22, 2024 at 7:25=E2=80=AFPM Barnab=C3=A1s P=C5=91cze wrote: > > Hi > > > 2024. m=C3=A1jus 23., cs=C3=BCt=C3=B6rt=C3=B6k 1:23 keltez=C3=A9ssel, And= rew Morton =C3=ADrta: > > > On Wed, 15 May 2024 23:11:12 -0700 Jeff Xu wrote: > > > > > 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= will > > > 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 a= n > > > > application would depend on this behaviour (unless by accident). > > > > > > > > [0]: https://lore.kernel.org/lkml/20220805222126.142525-3-jeffxu@go= ogle.com/ > > > > [1]: https://lore.kernel.org/lkml/20221202013404.163143-3-jeffxu@go= ogle.com/ > > > > > > ... > > > > > > Reviewed-by: Jeff Xu > > > > 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 t= o > > - 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 agree with this. The current memfd_test.c doesn't have good coverage sealable vs not_seable, most tests are created with MFD_ALLOW_SEALING I think the test_sysctl_set_sysctl0/1/2 need to add cases for no-sealable memfd. because the change will also change the behavior of the sysctl. Do you want to add them as part of the patch ? > I have looked through Debian Code Search and GitHub, searching for `MFD_N= OEXEC_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_AL= LOW_SEALING` > behaviour[0], and tries to work around it. This workaround will break. Lu= ckily, > 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 prepare= d a PR > with a fix[1]. > Thanks for the investigation. > > > > > Also, please let's give consideration to a -stable backport so that all > > kernel versions will eventually behave in the same manner. > > > > > > 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/9eb0b7e5826fc76cad7b025bc46= f267d4a8784cb/src/util/misc.c#L114 > [1]: https://github.com/bus1/dbus-broker/pull/366