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 AF95EC25B76 for ; Sat, 8 Jun 2024 03:35:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA16A6B0088; Fri, 7 Jun 2024 23:35:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C519B6B0089; Fri, 7 Jun 2024 23:35:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3FF76B008C; Fri, 7 Jun 2024 23:35:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9806C6B0088 for ; Fri, 7 Jun 2024 23:35:51 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 05CCF140595 for ; Sat, 8 Jun 2024 03:35:51 +0000 (UTC) X-FDA: 82206307302.07.7399D3D Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by imf09.hostedemail.com (Postfix) with ESMTP id 31F38140004 for ; Sat, 8 Jun 2024 03:35:48 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FRKc7Bgj; spf=pass (imf09.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.49 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717817749; 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=KltA1s7VUNRTd1PbGmK6izLRZPTrGICXXbndgUz/sSI=; b=Zl2F+Pt6i5mbasLCEaB7v/aDo/RbR/KxtlijVMPri3l9Wodk2Xz7wWPdd0UJ0Qk076yVb3 bfZBLVAWfhAnvMAYJq2NpKdJQGmoBZOwhR8n88xtZdevc2PNbZfW7xS6/1ckSLiqg7tI6z dOR1yaGWkMi2DAaGPV51iiT5dqSFnEE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717817749; a=rsa-sha256; cv=none; b=CUmNhtzjboyMCj8Bm6HKl7Acc+pNrpoBRQaEcLXLIMA/Q4TORoqtyWiOj0AJb81IDZIk+H gSbQeCB8+BuLDepNs7EcEVZhVPYxvuGKGKRiWXdnhFla+0st8Nms4H/faB5SOAOzuO9A37 b7JFJWDiSlvaE9sUZT47S8aHMf0ZDU8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FRKc7Bgj; spf=pass (imf09.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.49 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-5babfde1c04so552208eaf.2 for ; Fri, 07 Jun 2024 20:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1717817748; x=1718422548; 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=KltA1s7VUNRTd1PbGmK6izLRZPTrGICXXbndgUz/sSI=; b=FRKc7BgjUfK/s9XZNjM/PPiJtEkjjg2NxBmCy8ZBf8gKV099dqGbZM6xIHmXGCO7z0 Gl7UMAmGu9Ea0w0KOkPBZXQxuRwKNR6xHR68CwzDBD8pBSI/n3Bj51d6glKJ9ILvDKpo KrmwM4FyWSY2Aq+tdUvCIbox4f2qxg1ypnkBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717817748; x=1718422548; 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=KltA1s7VUNRTd1PbGmK6izLRZPTrGICXXbndgUz/sSI=; b=iAaC/BUsmmhRKGCUZwgWlXj9qppFtoptfm+uRzqJi+Sx1ZyqQQqvxxuXN0YlTkdKyG 8MkPpX4FP8THcfmIjiXcnlD2/WmZD1EdBl1wl7ryHxqSXr1fv7O2ox6X91Fm5eF+6/Rt O5qW/yob0rJOOfUT7HpLF3WaW5BvnzT637S4DV5eVJ+kxw0kSSD0FwmvoDpdn7GN1mHb YAK2+1bLo9x1agHZpREXhwVQSYzkEf9t+BqB7YrexKa2IRQmL+iHjiGZKUSXmerIaFRO G+vABLeEzpWLJAY8JGMHDTQ2OhNAB+kiPphwm6CEXi1w4mozgjCX5446giusDF/TbCs9 l4hw== X-Forwarded-Encrypted: i=1; AJvYcCU1l5ou1aTk5yDg2mr7sq2JYBhhtI5rCE4F4urDhO71yzfe36iBhHNcA2VSXgqNK/CykBmKD6RdJEmvZPKlWwY1Ygo= X-Gm-Message-State: AOJu0YzbrwuGW18GoxG3zP+QeV5FdpOf8BQs5HeqNfONYcPJ+bQ/+kxt CTuA1cVkulW5XKf5pN1r15K5aeXepY2ZsWEO0MM9Z1PHY/rk+XazIdumFmOqyHKhUb+GLzB35wJ ZohaJIl7P2Kp6HpN7lEBhM2nRuhjOq5BpLA50 X-Google-Smtp-Source: AGHT+IHe7gxzs1S7pNTTl7STORIz+GRGHc0QiiXOdUo7yjJfr589hzZyCwwwlTqDVLMo3BR50OLM0QbpBVL2TtpA0Kc= X-Received: by 2002:a05:6870:b507:b0:254:8c7b:889e with SMTP id 586e51a60fabf-2548c7b8d0cmr1716996fac.16.1717817747891; Fri, 07 Jun 2024 20:35:47 -0700 (PDT) MIME-Version: 1.0 References: <20240607203543.2151433-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Fri, 7 Jun 2024 20:35:36 -0700 Message-ID: Subject: Re: [PATCH v1 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL To: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= Cc: akpm@linux-foundation.org, cyphar@cyphar.com, david@readahead.eu, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jeffxu@google.com, jorgelo@chromium.org, keescook@chromium.org, 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-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 31F38140004 X-Rspam-User: X-Stat-Signature: umcydrgbzeak7q99adu5tfwuomka5gsd X-HE-Tag: 1717817748-147113 X-HE-Meta: U2FsdGVkX1+LzN3uT9xe/HeQ1v38GHkC9rs/DeOWb1Pe6ImhNbhJGa03vsInOfqFQVolV5VIK/gIjaBEmYKomQToMtv0sbthHGepGT7CxADpHQPOeFXw4J1D2D9EIYfGxenrV1QEQM5SRvpS7x2dbDdOgrqvRmNGRAj0geq6N0DtKrpceqOTs4F1GkBZKI4Qw09gJat1B3wPIuxZVoCQEjnpI35go4bb4IiJX0cdTN63wM7b/vr/yWQ9a3bsPoPPrHrm9n//fBPSYkdl7kKlVQ6KAAFQzgnV9IzZQ1QiVcuQkSRl8EhA2yh4koToWjxTvrne5tzt1u/AdGMBUAQCHkgv1F64lIIpvhOR5h8plYFhPAw91szDsxxv47mMfUg43JXmmQ6+Fi+jhbyKIfFFY3/tkyIDxkJsFAdAhpfaAw5TsuWiuPIOrZota+ha9USPWiTGN+HBAAS9iRR8lg0n+5fOvUr2I1IpNnoTgLyPiHlhDiUzQ4gZHinole01i3p+3zTtiIOYWbrQXatU2QOgOMHjBPGzYetBOe2g0jJCSvg/8rrD0QriegOKmEZjih/JMz0hpjCEOUmEa3QTJHadIyq5DlW5gynEqRTj0oNDDCQZpku1Eqbp0yJQTq/7Q9tT7y7866/nfjucu3iPi0g+md5NZyRdl8u6nV6sVCxujHKRsdeujFlhkwfaWnENuc1MqEMO9SnuqvoBp5/Q9FyP9zjKyXEpsVURyH4rE/28oNl1g22u0WBfvx/NaI/vpiCNv6oZIYrr/Luetovc2LwAFizH5lPhujDTrhfq6xDCY+byjJjC55TRsmCLt8+RlSYEAtWmf4bHbylzoE5bpT+7G/bAIv1oq11hHoVzWCbuOccYc2J/B0qI9WJC2EkwAvFTIxE4D+Mvt+vzhXf+Q7r8fnoijTvHR0SskaZ9m1DhESTYDnRL3TlmpVyrpuuPwVS0Tg49S03ghna5A7ogUqF IBRHKeca CufsjPGzMd0XW7x6U6vzxJn6n2++9IP3BFDL00ogkU9XzoBJrhKlOWvV8ILPi9pERJzmJbcq1WJJ+n5NT12Wi0UB4w239JxyV/p0qSk392iJWJYIAThHh9KGPWCGH4y9+mqwel1zX52yu/jD61GDkA7truaRzhdrXI9K0/XJc1MuBK8HgxMFisIEsIMTk3SHm75mN+IF7mDAGN3FTExqSdnKQpoPxJzYgTDAdzriZG3eJFQ/IKgRmoMvDTR0LDBzmyNY8LRNyHnR0AhOuGgGkDZqHr3OStkblu2qT7wO+TaIYGigvsPLl7nqfURvA+c8VpSSOJqZr9xu52OHFv7aGh+DTxtSM049xBl9MA8TEKPZZAHwxEryr5KE0ttUeDgvlLu31VylxiDlqojpp65TtsQJHnk994rzU4lTPKkoRcWcxzj115XGXL9f98Hzv2Is6aWq3A+EsmjkW01zv+0qAVCSKAg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000207, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Resent, (previous email is not plain text) Hi On Fri, Jun 7, 2024 at 2:41=E2=80=AFPM Barnab=C3=A1s P=C5=91cze wrote: > > Hi > > > 2024. j=C3=BAnius 7., p=C3=A9ntek 22:35 keltez=C3=A9ssel, jeffxu@chromium= .org =C3=ADrta: > > > From: Jeff Xu > > > > When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it > > didn't have proper documentation. This led to a lot of confusion, > > especially about whether or not memfd created with the MFD_NOEXEC_SEAL > > flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set > > MFD_ALLOW_SEALING to be sealable, so it's a fair question. > > > > As one might have noticed, unlike other flags in memfd_create, > > MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea > > is to make it easier to use memfd in the most common way, which is > > NOEXEC + F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl > > vm.noexec to help existing applications move to a more secure way of > > using memfd. > > > > Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless > > MFD_ALLOW_SEALING is set, to be consistent with other flags [1] [2], > > Those are based on the viewpoint that each flag is an atomic unit, > > which is a reasonable assumption. However, MFD_NOEXEC_SEAL was > > designed with the intent of promoting the most secure method of using > > memfd, therefore a combination of multiple functionalities into one > > bit. > > > > Furthermore, the MFD_NOEXEC_SEAL has been added for more than one > > year, and multiple applications and distributions have backported and > > utilized it. Altering ABI now presents a degree of risk and may lead > > to disruption. > > I feel compelled to mention again that based on my investigation the risk= is > minimal. Not to mention that it can easily be reverted if need be. > The risk is not zero. If we changed the ABI it would be propagated to early kernel stable versions. Various Linux distributions also backported the patch to earlier kernels such as 5.4. If it needs a revert, then everyone has to do it again. > In my view, it is better to fix the inconsistency than to document it. I = would > argue that "`MFD_ALLOW_SEALING` is needed to enable sealing except that X= YZ" > is unintuitive and confusing for a non-significant amount of people. > I understand, documentation helps resolve the confusion, the next step is to update the man page for memfd. Thanks -Jeff