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 59DB1C25B75 for ; Thu, 23 May 2024 20:45:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0C146B0085; Thu, 23 May 2024 16:45:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABBA66B009B; Thu, 23 May 2024 16:45:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AA306B009C; Thu, 23 May 2024 16:45:22 -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 7CA756B009B for ; Thu, 23 May 2024 16:45:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 033AA1A05F6 for ; Thu, 23 May 2024 20:45:21 +0000 (UTC) X-FDA: 82150840884.08.9F909CA Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf10.hostedemail.com (Postfix) with ESMTP id 2A57AC0029 for ; Thu, 23 May 2024 20:45:19 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o1aHnNlW; spf=pass (imf10.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 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=1716497120; 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=Y6N+gKnd70b4DwOAlz3Ao0iTefD/C31XiD4R/jKiITw=; b=1Yk3Fjzsrf3ckBa0dp7sXVYGglDxiv2tJNtLngazhnTiQb52nxMX07ddLzYA1AMmwD+RP0 Pxsd+HqtuG8vSBHyLsZZsFxdg70ebxfJekicv6sY5qU6d6qLhTt4UaejPR4T/0u+7qHFZ2 q8lPSU9aAmCbIIN18Z9RrwEv7FCc5+k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716497120; a=rsa-sha256; cv=none; b=WEo4iqh5axXFI7Xfs/XpWVyLpR+JKcirMbgAmB/0c+pA75m17d2eVQIUeR6bnFCbF01D35 66zaAY52A1yoOdGVc1RSQXsoskknm3uSSa6lewzV7qiebhxoWvzt91tu3wHnu6cIOcXYnj ZoqKgYSEL1X79OftcC9gzeQFQUJMBEw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o1aHnNlW; spf=pass (imf10.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-572a1b3d6baso1126a12.1 for ; Thu, 23 May 2024 13:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716497118; x=1717101918; 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=Y6N+gKnd70b4DwOAlz3Ao0iTefD/C31XiD4R/jKiITw=; b=o1aHnNlWMh5tl9WkkL4qyEvN8HvB+uqOI4S7SkQdGN1QIJLD86+jCJpIz1Dbcp4E7M nZzhp5ueWUpEFhiLmq+6GaC4tcJw5XkDAYwisLyA56yxqODOJ96r50rwC6UgxiLH1Jbi wAWMCkGlw05QS5dZ07qQtRNaK31eBBR0utmzGNEWLvyFsrH1rVzeTRuADD7qCSTnrfif kiR2asHmjwxXv/zdy3i2pkVndhED6ZVUXBSLG82L6jpwsUsMqouVu4V3D+83ZfZrEaiX 1pt1PmqVjt0mR2TFzhD2x2YEV1cRtWUDAhDNiaYr9t3QYGszkNjojo5Ub05Y+rYLZSi5 sIAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716497118; x=1717101918; 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=Y6N+gKnd70b4DwOAlz3Ao0iTefD/C31XiD4R/jKiITw=; b=YqEUExxKzy5WZqjI8MnnHHVA6DlJKZwrnUIO4GG0o27tCerarwqRm1TA05tMAuwiwx jTNRaIKfJyEzlAZz+EZRCKJgN67uG03B1Nz8mzzIeQ2Pm2r7SVH3uMkfQiywIttCsJcZ zgSRtvEe0j7QBHQkxo0Jtv31XyfDLKMJoVIsH2LO3RgBuNHACmXCYJbPhVpwf+v3YfK/ pz0LfV0f9R7q4HVcyI2BraL7g1/2nt4XJSgRjdQHA5NTn9nLlLvT10KX+mhrhdAA78C3 xye7Dt91vh04YXNZSFE45FAHicrDo7qRMD1ZT7ZrD9sVcXHmhaXw9jqvAwAkgTncTpAV O0OQ== X-Forwarded-Encrypted: i=1; AJvYcCXVvtzJ6h6mh7hiM+WR9neJsuohguFPXC7i6mIqcv13WZ1DswnMd1/yfM0EHNJu2IQfBYsOp5jODK8HOwFO4X85kP8= X-Gm-Message-State: AOJu0YyEFZACGUYHVHBE7A7SLokvsvxHd4U7007PlrTKuKhF0rseKzMW kbSnR+p+GNk/S8Tk3F6wlTzoxGgJHTTtJGHj08+RWKteWeplzS2SFXbYSgZ6ugPvgyYODioyv4+ Uva4xs5tICQyULAF38riC+oPtvReFXU3rWZNqr4rVAAQ9yGrWN2nW X-Google-Smtp-Source: AGHT+IHiTb7B2MfFZEs9Qb5GzWN3bD/f4uhDiXHK/UKzqmvTIF1G3MsIOI76EbjynZVznxCrfIiN5R+oVDmmd2wfv/o= X-Received: by 2002:a05:6402:74e:b0:572:a33d:437f with SMTP id 4fb4d7f45d1cf-578516800dcmr52317a12.2.1716497118262; Thu, 23 May 2024 13:45:18 -0700 (PDT) MIME-Version: 1.0 References: <20240513191544.94754-1-pobrn@protonmail.com> <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> <20240523124521.99a798d645b0939d331d70c1@linux-foundation.org> In-Reply-To: <20240523124521.99a798d645b0939d331d70c1@linux-foundation.org> From: Jeff Xu Date: Thu, 23 May 2024 13:44:38 -0700 Message-ID: Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` To: Andrew Morton Cc: =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= , 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-Server: rspam03 X-Rspamd-Queue-Id: 2A57AC0029 X-Rspam-User: X-Stat-Signature: 3mgfh3rkhnmu3scgd9tbknjpqnqnnruo X-HE-Tag: 1716497119-518890 X-HE-Meta: U2FsdGVkX1+0bir37Gx5RGmBjLtno46bgixgmwBdw+zAAUV1Ovx5s5IpgMRtAJ/dpCj6iUUxurfthjb7kj6xamuwMuRPMkT17v0RaLHaAjjbWVn35Ck/cvATRhRWb+5QfeFImreTAQ+OxdhCkwlBM9Z4NOmH/Dq0y0iUy50xesD4SKym0HoR5q4lbiA7X1uu7Q1u/nwN+HlIeen6ELr9jhVj3/l3BcFn0A6CFzZZf+go7Dd5+mv2wNOEw3y2MvTZpmDlRHs38ka/a/5kfKheWBAXvf5+BuDsnDUHYhB/qp1saFuVBVTJ4w23HRber1+tTs6aGZgcoNYjzV1/6PuUk0ozce2NXo9iI4a1o3fHCVtSL31R05s+my+EdMMJOLW7H5ZWGcXOIJ1GEIhQSTwtPZAnkP7h7ZNZmwqoVb6Hx7ZO3TYLgLX5IqUtIzEPaKcU7p6LGtbnUsa5u14FHAkx4N6Jnt+glJ3/DGGFa4ZAOr7cjHjujX/hNomc4BvBQnodCpTEWdVnATMaGs9dLghyw1TzSpPLozuk+szH+wsz8ds130+MJWEwJpB1cJmYYdcKt9MJqjKj6nosjbvvyhRaiPqd28CysPTsjgfaWycTCvNJUkYdW67NJYC5HQ0nMQyDrun5o16fcwTUQsCxB0mqXKL9xR2AyhmgSJ5W61qIpxxFL0HNK0aoqPBbdoStVltFdWEWfH0tjElGZt8v0cFFQszqGpHzxXjL0Hlfk5t/vJciXfVhny6Y2diAE75zxuZ6+xVkfnKwwsgsRpYwE1K8i3vIfLFeCEx/gT/tmtep/j8GCMgS0Yf6EyXFzRIbZa9xx4QhGOLXmV7QB9k+W4nMhayHOq7YPngeznfHAnyt09xm+EX3qb75aVdp4nYohKKsVbdLofhuws6esk1zg9EB3jV1ohI/Qeic7pMS7YTHeEId1Bv75d41aQJ6xQrIQQBUpYajOQ4xg60M79b2ce3 FyiHvvew bfg4h6wlSYbzH5iTTU+SUTWPuJKd97aCcNF2SLUiRyJ3qXOptnZg7inwULZoN2bbBl9HhY6/Mt7QoiFIixoBtuH5+PBL5Nv8D+UmoA+ijRacMdTTnTuvfpO+f8shWAT1ujzcc1Iri45BK2OBkoLG/Hz1wlntLDz2Ne51QbyPsvofgDyqI7qtouCVmyhhQUqKEEID3nzlQuRv8unLA5iNfy4/LL3oY8jVzlo1JmBWsKP1kq+969uRpgIMR8wAsLXkkKISAAlMwmS7YN8r42pUKnR7MJZiVx76DJrHjQ8mwGV5KTgg2gFy0/vZ0Vtz9FsFr2k6pfkBo1GhWHzfNucSsvlqI+kInPqmYTdZ9AyNwB0jkdlgeH+c4X/NtGGd45u4r4MhE66Od8FBVC3yWF45WdSJ8dvijvSjVJ38tr+pb5w4LuDI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, 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 Barnab=C3=A1s Is that OK that I work on V2 ? It will be based on your V1 change and I will also add more test cases. Thanks -Jeff - On Thu, May 23, 2024 at 12:45=E2=80=AFPM Andrew Morton wrote: > > On Wed, 22 May 2024 19:32:35 -0700 Jeff Xu wrote: > > > > > > > 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 user= s. > > > > > Unfortunately, this is a breaking change that might break a > > application if they do below: > > memfd_create("", MFD_NOEXEC_SEAL) > > fcntl(fd, F_ADD_SEALS, F_SEAL_WRITE); <-- this will fail in new > > semantics, due to mfd not being sealable. > > > > However, I still think the new semantics is a better, the reason is > > due to the sysctl: memfd_noexec_scope > > Currently, when the sysctl is set to MEMFD_NOEXEC_SCOPE_NOEXEC_SEAL > > kernel adds MFD_NOEXEC_SEAL to memfd_create, and the memfd becomes sea= lable. > > E.g. > > When the sysctl is set to MEMFD_NOEXEC_SCOPE_NOEXEC_SEAL > > The app calls memfd_create("",0) > > application will get sealable memfd, which might be a surprise to appli= cation. > > > > If the app doesn't want this behavior, they will need one of two below > > in current implementation. > > 1> > > set the sysctl: memfd_noexec_scope to 0. > > So the kernel doesn't overwrite the mdmfd_create > > > > 2> > > modify their code to get non-sealable NOEXEC memfd. > > memfd_create("", MEMFD_NOEXEC_SCOPE_NOEXEC) > > fcntl(fd, F_ADD_SEALS, F_SEAL_SEAL) > > > > The new semantics works better with the sysctl. > > > > Since memfd noexec is new, maybe there is no application using the > > MFD_NOEXEC_SEAL to create > > sealable memfd. They mostly likely use > > memfd(MFD_NOEXEC_SEAL|MFD_ALLOW_SEALING) instead. > > I think it might benefit in the long term with the new semantics. > > Yes, it's new so I expect any damage will be small. Please prepare a > v2 which fully explains/justifies the thinking for this > non-backward-compatible change and which include the cc:stable. > >