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 EBDC3C27C65 for ; Tue, 11 Jun 2024 22:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FC2B6B0106; Tue, 11 Jun 2024 18:41:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AB096B0107; Tue, 11 Jun 2024 18:41:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 498D56B0108; Tue, 11 Jun 2024 18:41:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 29FDB6B0106 for ; Tue, 11 Jun 2024 18:41:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D58BB1C1EF9 for ; Tue, 11 Jun 2024 22:41:12 +0000 (UTC) X-FDA: 82220079984.26.0841A81 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf03.hostedemail.com (Postfix) with ESMTP id CCF1C20002 for ; Tue, 11 Jun 2024 22:41:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=oYfRHv+u; spf=none (imf03.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718145670; 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=ywBbGaPOeq2fMv0XWMs74qxEU0SIGLuY7vHTY5iY8/k=; b=poKmF1GAoNDVmZv3BR4gPmvkacn3+EITTrNNFmiWGa3RZPZQhmInnC8z49JB1tOuvgAlNs GEEp4JkbkVLiUggRjsEuRDTOq2WNkDCKrIHSS7iZN31p07EhVZvjKEwLFcjKjmzVPjoai6 SdZm0g1ShUTrUHjCzGibIoG7qafdCn4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=oYfRHv+u; spf=none (imf03.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718145670; a=rsa-sha256; cv=none; b=teibjPzXCzyExQK4Kg1kt9q1jVA9ILWUVoeMvvw+6LD7xUvmujmyigrWBCRUwIxC1IYyoU hvPNPzBTskEcOJfQHuk+kCCJXaRoSCX5a7ZdmHHP5V0pUpyuB4fK9iV1zYnFO0HburLWfT PMe3xsD5zmpnpNLIKnmQ6bK3uUuJ10g= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=ywBbGaPOeq2fMv0XWMs74qxEU0SIGLuY7vHTY5iY8/k=; b=oYfRHv+u76v9FmwrmVNPqx9Acx vRC8Qia98qviQJkpLtLhmC70Kzmp6BgZiYZ8dbtnmSvv6PlG5AXS821CxgaJu+unAv0KTvOt2HZUi flJ50feCWZ4gblKUmybyg/eIDnWEgtrdrIoKCa1ulwlg7+1w3Q1CbWcAcfiW5ETJ8+RcEpaL9EGL+ jeAKBbI280YfuY4zgFggRWPrQJB3VA3UqKnEICeNtE2Tlqwkhgoq83k5vJPD212DK1m/zjISUGvlb yNaTnzJPITdbXTgFh7FC/lJBVd/xicmdqm0BiSLQiSpRxq/nsZ6Dv6DCWB8zl28Y+pvL3VIYdxBlN 9KrOvEZg==; Received: from [50.53.4.147] (helo=[192.168.254.15]) by bombadil.infradead.org with esmtpsa (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHAAn-0000000AQia-0nYq; Tue, 11 Jun 2024 22:41:01 +0000 Message-ID: <595b6353-6da6-432b-96b4-42c4e3ec1146@infradead.org> Date: Tue, 11 Jun 2024 15:40:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC To: jeffxu@chromium.org 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, pobrn@protonmail.com, skhan@linuxfoundation.org, stable@vger.kernel.org References: <20240611034903.3456796-1-jeffxu@chromium.org> <20240611034903.3456796-2-jeffxu@chromium.org> Content-Language: en-US From: Randy Dunlap In-Reply-To: <20240611034903.3456796-2-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CCF1C20002 X-Stat-Signature: h35w4wyyd3u6k4oh6hz7wf7nguydy5ta X-HE-Tag: 1718145668-787318 X-HE-Meta: U2FsdGVkX1+91dBBBxFE+iHxnRqsadqBlX99M/16cXEjjU4Ic8MxBgmRRueoiY6a3QZh2+vq8yUrKhq1xr7B82gSsPop6FEdTW2z5uoqEQHjBCaCvOp4bNITWC8cXyjZadXhL/RJXA81LCzNbEq3BFWuZvs/+Ixv349G7XrnYYOtFnM3jN8+J1cPdsScUvwqGdICzaJMs69M1iDniQchp5NWgVfyq29Zke98/foMQ+lYjv0TlPPPLJKeBN31aWdKt1I9QdZnKpLMRSxsusw1+Zn3Z9o4yAXt084gRX43G1a0NSRnlMgp20OMsZ73TClBEurKAnins34jkmA1+aIZ6lSmfbdoq3dlPjrzHO084TjNzaZCK4Saqek1fLZrWWg20GtBbgv8wVNjZxk8vUVqClSnNnDOHN/8BmjQ0ZEBm0mAACjkx659rnGT6Rwtgtth9Tkn1buCdwNhfyMPqrBv17ciEJRCaqgrl0cb9Etuk/D/BR35mcPquqzIcrYmXCkbeFtgHsH8k76173o4XaA0i6DCayO+CBYZAO4khvizcyltGpT0HIKJ7XKib+h/jkmTwUth1AQyA7Ri9rut5dhcU3GyrGA93WtBbe2Vc6UHmrpFvIjWFW9TbFbTbZNbz3B1a+ZU2N2j+mARn3IfqGSFZan7xI9DXJ35WU+esQlcYb2KILWGCOienTYYPidf38yvXSDWYzBqmd0b/Owp47NDRJ/EguLpvbr8k9gfRrMDampFk9U45OLIRFT51jAi6HqsB9M9tOl9pJYu7LMXMbpAx/7BtOdQSgY9uoeXvp/+U4FfXq0YA7iK7mRd1FKm+QvDT6P7KjRhMBBALX0GK/svJEYWPmPh0Jjaiy7UJkrN1eejEi6DE/Tk7/UPcpyIIlhFlK+BHHvZCkR5rlnLBmIzioE2kgg2tLL6NcKzha4JHK+Blme9U2y36kPVgYy8UO9VNhpJ4K0Vq1u9aVya1pj KpRRoz2P 0r03wtaCNPYfvqC+u/kMV9cKzkQOAGy5FDHxaw0LcAoVJ1foe71Sydhr+lVkj4YtLiNPnmVd5RYw2ZZfKPov3DoLlJLtwzP58HTsUJUoGKXbzwD3FzNLq+vx+3fI6eJ5EsNsY4uBqQczQbUY7j/p1qehq2BJ6KusZGfzGTDS8IzK/Pg4Sw3Pphe9vNwUYeY5Nsipa6zneCD1ZIWTK9tVr4/OjSDKFkMYVl4+wwu3sZfK01S7+x2mQ4dif1XP/Dptp6boQuXnpRYB2RHNyRVwv3ASVGEBJbL3LPGTPDXpIRYCf7p8MRwlFkTSjiK8hGRe9aNR9OdqsYxCyxIjnsSGQzb/kg6G8v8lOEQ2bgI4pdLCUoF80lIs6V1Heb1dbbpsvE4U1ymSZb8MUakQ2tr+DdeLjkQzfr+QXAingBOHaKtkcIfewz07zq39172/JCNxFEcgwoYgvjAgpsq7wQlxr5foOKRdqCXCRClRQdAYT7eAtcZ3SD8vnHQaiD8tJeNB1NarIrpyymYJJZvieDODifceTvxnC4XT7nwpD 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 6/10/24 8:49 PM, jeffxu@chromium.org wrote: > From: Jeff Xu > > Add documentation for memfd_create flags: MFD_NOEXEC_SEAL > and MFD_EXEC > > Cc: stable@vger.kernel.org > Signed-off-by: Jeff Xu > > --- > Documentation/userspace-api/index.rst | 1 + > Documentation/userspace-api/mfd_noexec.rst | 86 ++++++++++++++++++++++ > 2 files changed, 87 insertions(+) > create mode 100644 Documentation/userspace-api/mfd_noexec.rst > > diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst > index 5926115ec0ed..8a251d71fa6e 100644 > --- a/Documentation/userspace-api/index.rst > +++ b/Documentation/userspace-api/index.rst > @@ -32,6 +32,7 @@ Security-related interfaces > seccomp_filter > landlock > lsm > + mfd_noexec > spec_ctrl > tee > > diff --git a/Documentation/userspace-api/mfd_noexec.rst b/Documentation/userspace-api/mfd_noexec.rst > new file mode 100644 > index 000000000000..ec6e3560fbff > --- /dev/null > +++ b/Documentation/userspace-api/mfd_noexec.rst > @@ -0,0 +1,86 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +================================== > +Introduction of non executable mfd Missed: non-executable > +================================== > +:Author: > + Daniel Verkamp > + Jeff Xu > + > +:Contributor: > + Aleksa Sarai > + > +Since Linux introduced the memfd feature, memfds have always had their > +execute bit set, and the memfd_create() syscall doesn't allow setting > +it differently. > + > +However, in a secure-by-default system, such as ChromeOS, (where all > +executables should come from the rootfs, which is protected by verified > +boot), this executable nature of memfd opens a door for NoExec bypass > +and enables “confused deputy attack”. E.g, in VRP bug [1]: cros_vm > +process created a memfd to share the content with an external process, > +however the memfd is overwritten and used for executing arbitrary code > +and root escalation. [2] lists more VRP of this kind. > + > +On the other hand, executable memfd has its legit use: runc uses memfd’s > +seal and executable feature to copy the contents of the binary then > +execute them. For such a system, we need a solution to differentiate runc's > +use of executable memfds and an attacker's [3]. > + > +To address those above: > + - Let memfd_create() set X bit at creation time. > + - Let memfd be sealed for modifying X bit when NX is set. > + - Add a new pid namespace sysctl: vm.memfd_noexec to help applications to help applications in > + migrating and enforcing non-executable MFD. > + > +User API > +======== The rest looks good. Thanks. -- ~Randy