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 6A17CC27C53 for ; Fri, 7 Jun 2024 22:31:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC8F76B009A; Fri, 7 Jun 2024 18:31:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E78096B009B; Fri, 7 Jun 2024 18:31:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D18AD6B009C; Fri, 7 Jun 2024 18:31:28 -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 B23F66B009A for ; Fri, 7 Jun 2024 18:31:28 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2BD78C040D for ; Fri, 7 Jun 2024 22:31:28 +0000 (UTC) X-FDA: 82205540256.19.BB9F3AC Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf06.hostedemail.com (Postfix) with ESMTP id 5EB9018000C for ; Fri, 7 Jun 2024 22:31:25 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tnV2RNZy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.41 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=1717799485; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yRHFAJp1ZcML3upLim/OYyJehLTPhR/WDZx13ZYtLdI=; b=tmDrawR1j3BZStqwPKAxpPtIaOkUSE9fxdHlcqn1O/aqM/pZUj9qVC7pzkMA8yytiGO1mT wHO+nx31096JKABDXx3ajKBZuJ7XEGhIgZvuKQiVzdLTBRIqmX0TWBEq1f4TaXwAerMehR ydHM3x+XOxjJZ6WyYTZ9+TaxOjgThY0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tnV2RNZy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717799485; a=rsa-sha256; cv=none; b=yDz+G8umXB4Nsvkp2FadiPbAvtFxh2qHIoM8535APt1D3b6QzWDNdqDdeJ6dPX1bqSbqk6 3ptGQ7k669MOgS2xQy2xSuJXwxmM4Tor+2mFNY/n9gwYtdYlcS66s+IyxGo8OovuLkLLee tlxHzUHikMRss/yWhrttiz4XoJYa3mU= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-57c5ec83886so2279a12.1 for ; Fri, 07 Jun 2024 15:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717799484; x=1718404284; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yRHFAJp1ZcML3upLim/OYyJehLTPhR/WDZx13ZYtLdI=; b=tnV2RNZyMcaK0l2UpBokDbPW999j5h5nArgElncPDGKcrSUpbVfnnaVyNgOXmIEhrC UDJhF8rak5vGipZBjWAXoA/u8FhAo60IoA355IGoNMT3RcSPkyb7NXC+ezDlql4FxPTl UbBPhbNu+C+yMaKB4HKMQzEv6fPMZRvL44Gcs3o29ef8ZcmMFiKEZ5/1ALy2Z/NwgQnG K1QxDo90gLrlRFCFbV0zYIhzU3YkqU8FW1v6TFh9byXTS2G+mKMycV/FuFTLQqH2rkI6 PQ67sDwinkScnAe5jCOd4W6MPCHOpcqjkOVsHm61+LysbOjDzkQKIRu7VCUUdX8Qy8vb Bdqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717799484; x=1718404284; h=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=yRHFAJp1ZcML3upLim/OYyJehLTPhR/WDZx13ZYtLdI=; b=rDoZ2kU+cBrjSGL8zJwQex4blKavZcG4DWCC4YVjendIk4F0KN1xHLDct3sQi+8POv B1YZxv5fhdhHCJZShEBlmrry+ncEnPbIijgdX/lt4WpUJPcUdMaxNCgqNuHyVWuFg8Of ibw/AwD/w7ZMuFiKlWi5l3BO1usjVqYtvWTGg5NQDfTPRQi2d0u20uq3ri8H8Gb7Kswb 49eqndbV5EpvG3r/V9foTQUTHu89DXduyFCqajTnJqbrTID+0l2HuE29AiAuhbomvJx7 8OduJImIRGQ/gs4bVepp62PRJC+Z5sF0byqXLHdeaKjoAFZzmPj4qN4oSeZYrK1/6QVA zywA== X-Forwarded-Encrypted: i=1; AJvYcCWxAK91btTqlAcygONn1F+Dmzs/cKl0/e5HD+oRHzwBrNuwd9uboifOImbrseybNu6oTvjtfxTUPMnJ/1xOpui8658= X-Gm-Message-State: AOJu0YybtNyfb5Emj/k8yf4Qz6lVWiONUmfo7N6cQUEvdxYvEsF542Qe R4yv4nmlyN9hlHDNCNRjyyuALGOcCmplPiMMOKNFuUCMSuNe/14zY7qnxoJLKaLX1bS7sV3R1Zc jJt4368BKYQwcdsw9YFPIxkqniETs2yAjAaKQ X-Google-Smtp-Source: AGHT+IHbQIcOkusqarqjX8eX2MtScFBmJGKQRRTKisJZpRA78ez3C4J4yAvdklsevknk2GmG48gy+wjFVZsGSQd9rkY= X-Received: by 2002:a05:6402:2696:b0:57c:622f:7a2 with SMTP id 4fb4d7f45d1cf-57c6c4d9691mr28538a12.1.1717799483684; Fri, 07 Jun 2024 15:31:23 -0700 (PDT) MIME-Version: 1.0 References: <20240607203543.2151433-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Fri, 7 Jun 2024 15:31:12 -0700 Message-ID: Subject: Re: [PATCH v1 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL To: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= Cc: Jeff Xu , Andrew Morton , Aleksa Sarai , david@readahead.eu, Dmitry Torokhov , Daniel Verkamp , Hugh Dickins , Jorge Lucangeli Obes , Kees Cook , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Shuah Khan , stable@vger.kernel.org Content-Type: multipart/alternative; boundary="00000000000005a991061a545c9f" X-Rspamd-Queue-Id: 5EB9018000C X-Stat-Signature: 8f7drgkdx9xi16igpsmhsh5wpe6j8z18 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1717799485-207621 X-HE-Meta: U2FsdGVkX19WRZngxGghmzWtHB7zlGLZ35dZ8GsSs+6P0XK8xRY5DxNTRjgNvb2zlyE325yh3KMqfMmn2e4DhRDuyuzQZIlOOpa0ukBEXOfiI8erHXKUmMn3axFmxuAMdoCPrEFwu5sAspsX5PqTvM9shz+eFvo5GTxp9RN2aiwweFXX3tlWX9RnYq2JEuL7mcV+zgoF3geUpl0O7L1dl9mG4HtVo9KUdz1zKzqxXDh3E2R34OpTONrF2YANe8GDgwKYqt1M0oAi56TGBofeh4pJTvR9Vse7XhCciuekAuk7OZAi3IAK14Hp5u6fYoYoBtBNKKDGgyX7kw78qRWJ66a9EpQ8D0zQPLdcC4xv4Mms/TORflTiCtWPG801uLonRyZ+9BvTSCGLALF8LPbi2gS1vEwNrZiWJiY87jIuIpeo4RVfh+flvKqwYsZE/BANJiP5ZFsSgg7sD7YI8D12aB3NYiWg6WVOaAJsvYc2Ozwh7B7HQGTOK2MSTEQV5MTffI9NlXs/xgK//DsGgzDGkp/DqCTSfmVkqWsugiApgxJmrlm7afrbkwZUD0JLW65UxJN7vcKAawU/Yl+SXFUyg0oJ6E3hjYeIpd+SVVjpKiK6uKlEWlyVauHjgaKnD5vMaWGLnb3JtgWDk7XX5o2C/xQq0XCLv8uCWywJApq1kkYjSl2a6132WUE0Br7G5mRynKeAuvevfU6pQqMDzr5pMi5sOjHaZiIg0sH7oZhkVJy8w/HN41athXdCH84AYmxDRCy9sYcZ8BAS8HO5kUxAK6KjMBGyHId1bBfFayd5kDy87qhIsAJhgtPzyxGQBaomYFxewpKDVJZZj7LEgNYICSiMqq9121C+mZMURgIKIKpK/3ZczYp7ohCt2+drvQLSDmNonA9A4OwNRkwaUC1VKAyB2+YZTb3ErTbY9PrxD/XVKEmCzWxynr7MHFmMt6bZbybOhc4MbhIUs1IlF1z Mp/vl4u4 a4xBiB39H2N3aRd/OzpEMzhL0Zxd6ltQrOBWaVYvebComLHCokr1wvB3exA1xBdlhU6ON2kUVYcDoBuT55CXVPZUUXgixihlOqrDHsycg08VxUNyWjp576IhX2RwsKzr6SsPW/4Y1YGgQw5pI0nw2exzSjgOI5S9A74fDL+4rptlpxVl8X2/ansClUN8zsbVP9nhabyEb4WWqv8FU6/FkCErl90vIbmf64BHcHw4EHr2Zuy9dXTfsyvWYOm1QkyLAuiSjIrWx2zqIsVJqm6a+gS3XEyvKpeRo3KKv7EYhBeB4kvMcvMceCpbyP2uN4AFsytRhxdP+ZQo/fC4ZR0bP72xkDuTdsgspHvM6NA9yye9pPXIpeonq0D8uylcYBXJn/601/pNilOcRfPTo+izGnpk/d2dtLBJEPOxBT0AmVU21ZJO5T606IDJNAH63rGhbCufsCCiqrzxLa7OtVs3DHxLqfrSigB8wLgonXEB1B9m8tLgJ/kqRJk1AClStj4IsYKlLkHNe4ZcDaxts2PyI3ivnQSNHBt0NwEiDTIYejxkAA2rhJD3+JzT+EEHdxT0OZegZ X-Bogosity: Ham, tests=bogofilter, spamicity=0.002553, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --00000000000005a991061a545c9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Fri, Jun 7, 2024, 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 < > 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 > XYZ" > is unintuitive and confusing for a non-significant amount of people. > I understand, documentation help resolve the confusion, the next step i will updated man page for memfd. Thanks -Jeff --00000000000005a991061a545c9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Fri, Jun 7, 2024, 2:41=E2=80=AFPM Barnab=C3=A1s P= =C5=91cze <pobrn@protonmail.com<= /a>> wrote:
Hi


2024. j=C3=BAnius 7., p=C3=A9ntek 22:35 keltez=C3=A9ssel, jeffxu@chromium.= org <jeffxu@chromium.org> =C3=ADrta:

> From: Jeff Xu <jeffxu@chromium.org>
>
> When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it
> didn't have proper documentation. This led to a lot of confusion,<= br> > especially about whether or not memfd created with the MFD_NOEXEC_SEAL=
> flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set<= br> > 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<= br> > 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<= br> > 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<= br> > 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 i= s
minimal. Not to mention that it can easily be reverted if need be.

<= div dir=3D"auto">
The risk is not zero. If we=C2= =A0 changed the ABI it would=C2=A0 be propagated to early kernel stable ver= sions. Various Linux distributions also backported the patch to earlier=C2= =A0 kernels such as 5.4. If it needs a revert, then everyone=C2=A0 has to d= o it again.

=C2=A0
In my view, it is better to fix the inconsistency than to document it. I wo= uld
argue that "`MFD_ALLOW_SEALING` is needed to enable sealing except tha= t XYZ"
is unintuitive and confusing for a non-significant amount of people.

I understand,=C2=A0 documentation help resolve the confu= sion, the next step=C2=A0 i will=C2=A0 updated man page for memfd.

Thanks
-J= eff
--00000000000005a991061a545c9f--