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 C7ED2C4332F for ; Fri, 16 Dec 2022 19:03:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E63C8E0003; Fri, 16 Dec 2022 14:03:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28C518E0001; Fri, 16 Dec 2022 14:03:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1560B8E0003; Fri, 16 Dec 2022 14:03:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 010178E0001 for ; Fri, 16 Dec 2022 14:03:48 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B5B66AB9C0 for ; Fri, 16 Dec 2022 19:03:48 +0000 (UTC) X-FDA: 80249093736.01.1690117 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf21.hostedemail.com (Postfix) with ESMTP id E03EC1C0010 for ; Fri, 16 Dec 2022 19:03:45 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KBlw0Zv8; spf=pass (imf21.hostedemail.com: domain of jeffxu@google.com designates 209.85.215.178 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=1671217426; 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=t2+6atgOOmHW3Y6/BjOreIZzNs1w8s58OfIYvMq9s2c=; b=b+PiHszo99QOzL6Xbgeza/HjlGRW8ACz6QzrwQls5u0SCa1heqndvuKvZhWJ1B1HMCuafR 01U+6F9aY7M4+Vknp/unIQHTHFhDE5j0neRPo5eIVI/g6gvglOamID/2jFdT7TjTB4gX27 a9CyDMJCRgf4OFyDSUdI9WJ0WvbptqA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KBlw0Zv8; spf=pass (imf21.hostedemail.com: domain of jeffxu@google.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671217426; a=rsa-sha256; cv=none; b=gMcrXxE2jpW7C/x4ro/NNGNufAdnCqQ1vIXpmklVyyq0T9x5FLhv4MfX0BB17iS9YyxwUo oj+V7F15AF0MdTnmvpBxJmry440lioR73ong9rfRm+9xuXNeLtoPipWbllvZ6i7EjJsR7R y4sGrzS//lWoaLdQ7EfqFhzYcc8zuYY= Received: by mail-pg1-f178.google.com with SMTP id f3so2412139pgc.2 for ; Fri, 16 Dec 2022 11:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t2+6atgOOmHW3Y6/BjOreIZzNs1w8s58OfIYvMq9s2c=; b=KBlw0Zv85xGI/f7zBeWNnuUhEAWd6AP8p/mVZ2PvNRpLPQgPs5oHJLEvhdVVP+B/5Y MayQdYEgqMBwio68fP0vm2Qz0up6cD/PL9x1VK/v9WDid5KE3veOXRX3FhrQZJaQFYE/ fE4afr/+6N/WiVRjMAWr0r4VZlmt4FdcqdaR10I58q0Shh7pPeCT/9Uxh6XucorzU28o hgtM9QZnXfLyQLSmR+YN647tiOBOZPrsE+TDEAgCjBnA0WIx0yMkrBEQloA9pmRjdJSm pb45b4OboWwjXatSLEsxZQpwjg1rmP0yzkDqI4FCrhCcbOF2gEik9DTz4x2LyRGdF1gq 3+tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=t2+6atgOOmHW3Y6/BjOreIZzNs1w8s58OfIYvMq9s2c=; b=BlUMg0zGQbq+cNRciMGYXZU3AqK4TsDiDWRFGXsS8Hjhdtb5b4VEvyd/CNI3fjAkYK lzB+DqMpHNXEEkR9g9Nz7UMPZeBZzh1E5CfUVMd3gezdDVdC5n+HplKDX8TX3tc/f5ZZ JqFE1T5QMyvaWXPRuKuNyuV2T54gRHNSEdNNbEHw2QlKwPRuo9M3EJd4GqLifTpnLAhn dZ3FPZ2kClzHMBNV7hzSA3x1J4bRAanalJNV/SescIH2ZUCu9NQqKROvEQ0ELKsNBK9B 0/bHWbcM9UsIlTRAQN5ATcrhkSuknmoSK40PqJg55AeDVI46cQU3jYu7B3xdb0yKF0mj 6A8Q== X-Gm-Message-State: ANoB5pmY4GcM+fa9AEkvWVw8FgMEqfCEnDuDOUj3CuA2fvRDCieavaR9 M7B8h4FXdxbX91k1I3Doyw8caynRY6K/1wlzjcPdLg== X-Google-Smtp-Source: AA0mqf4uSuXyJGdBNnh0dTcrZ0uIDUxHYk0iKl8jaNcFx16JMkfVp7+9/n6i4JcZxOXpKjDBUCLM51XCRF7NvsRCoh0= X-Received: by 2002:aa7:8487:0:b0:56c:3bb4:28a8 with SMTP id u7-20020aa78487000000b0056c3bb428a8mr80681452pfn.83.1671217424499; Fri, 16 Dec 2022 11:03:44 -0800 (PST) MIME-Version: 1.0 References: <20221209160453.3246150-4-jeffxu@google.com> <20221216183949.169779-1-sj@kernel.org> In-Reply-To: <20221216183949.169779-1-sj@kernel.org> From: Jeff Xu Date: Fri, 16 Dec 2022 11:03:06 -0800 Message-ID: Subject: Re: [PATCH v7 3/6] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC To: SeongJae Park Cc: skhan@linuxfoundation.org, keescook@chromium.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, linux-hardening@vger.kernel.org, linux-security-module@vger.kernel.org, kernel test robot Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E03EC1C0010 X-Stat-Signature: rq6s7knwm9tqq3xjq6tqbx7tjqa113pe X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1671217425-467423 X-HE-Meta: U2FsdGVkX1/wlv9WLSJOxlfDrPbxNUzDZUHfwXFtdk96iwdQpA+RpqGAmfozAuMyF7yICNzygQtQe/bobWB0q+S1OI15iGmZuN576pZ0xDQz9i9NoggQiUAC1SpKB7eh2WfnC6hT8hQe8aXd/iMBt/VK/5bmf7wtYYSse4ehxoD20Sy8E6dxzKNYYsuy9PqAPqXxbgzgRasye+DGxo+IQCZUV8BYLl/8oTelW2GBij9Z4SMw59NuNLAKP6cOiPur6T2WO+c6vrXz/rk5UU4yr4wNHDM7JK57ffaXHDcNChcwVth/Y+UAsiLwGZzLcYpBzK8q5vnBuNKorwn44b06RVbqpv5y5kRTbXo6QWIXV7h7653fW/jVp70ipfMPuHXWQJyP04uVQ6+NwD5NA6BIIyyedgdUE60XrDW/18fjmxNt1WsKDPpJkuWm558cXKAPtIIZPF3Hxuk/B8YyGZRkOBCxPCAkWmQ63S1Xh4CeUKDV2jVqqoU5aFNm5LdnWZOIMAd8ulg5+/+SSpyfsv2m10AJmbWABvXl2Ovvzpok5n5+VMRgvtagk0Ifx1Jt0W27CVuJ8dknq8tegk6Bh0Q1ZBYXHTOoOI7zCv5E9FDpu3TwHzxs1spn/ZJYKDHQ3gSER3JbL7peSu10iQr7uH16dLCm3j+Ga/iKchIB4VYEevDO/pryRFHK6zvx18Uaf7uiTlcF8+X7Y76CXTMI/xVo39/N+lFwWYEnF1lFFPqLy6EXnzLrtWlVdVU9vwYZos3ScWaS2gUQoSJKKMkx0eM2TSlJ6OVTib0gVpy5P5CTYwXnusASEMolN1uMxSLF0Ru1fapR0PzOYOt2dfxQ36XQ4KjSQwl9M5p/DsY0rfuHoB61LSAYRHqbk6UJoQPgWJXct45TksNDd19ICZ5XoEALB7DY2JKNR6I9XvduiwH4FcYr//i0Vkbb/JprN6Ue8frBGEP6wGdBW+J6IYyDx6v RBn1cxwn 2ngvazhkvMzlZK66qA8ZOH64YzIaSSnIvB0iNsbVby7sTya/1NXXhITR0lJfgxePI9FgvEypiq6uqFGMEt9UzbjthDIxQEoupTHSfAhJmcVTw2wLIiA/o6mBjeJe7Ys60hjDu 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: On Fri, Dec 16, 2022 at 10:39 AM SeongJae Park wrote: > > Hi Jeff, > > > From: Jeff Xu > > > > The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to > > set executable bit at creation time (memfd_create). > > > > When MFD_NOEXEC_SEAL is set, memfd is created without executable bit > > (mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to > > be executable (mode: 0777) after creation. > > > > when MFD_EXEC flag is set, memfd is created with executable bit > > (mode:0777), this is the same as the old behavior of memfd_create. > > > > The new pid namespaced sysctl vm.memfd_noexec has 3 values: > > 0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like > > MFD_EXEC was set. > > 1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like > > MFD_NOEXEC_SEAL was set. > > 2: memfd_create() without MFD_NOEXEC_SEAL will be rejected. > > > > The sysctl allows finer control of memfd_create for old-software > > that doesn't set the executable bit, for example, a container with > > vm.memfd_noexec=1 means the old-software will create non-executable > > memfd by default. Also, the value of memfd_noexec is passed to child > > namespace at creation time. For example, if the init namespace has > > vm.memfd_noexec=2, all its children namespaces will be created with 2. > > > > Signed-off-by: Jeff Xu > > Co-developed-by: Daniel Verkamp > > Signed-off-by: Daniel Verkamp > > Reported-by: kernel test robot > > --- > [...] > > diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c > > index f4f8cb0435b4..8a98b1af9376 100644 > > --- a/kernel/pid_namespace.c > > +++ b/kernel/pid_namespace.c > > @@ -23,6 +23,7 @@ > > #include > > #include > > #include > > +#include "pid_sysctl.h" > > > > static DEFINE_MUTEX(pid_caches_mutex); > > static struct kmem_cache *pid_ns_cachep; > > @@ -110,6 +111,8 @@ static struct pid_namespace *create_pid_namespace(struct user_namespace *user_ns > > ns->ucounts = ucounts; > > ns->pid_allocated = PIDNS_ADDING; > > > > + initialize_memfd_noexec_scope(ns); > > + > > return ns; > > > > out_free_idr: > > @@ -455,6 +458,8 @@ static __init int pid_namespaces_init(void) > > #ifdef CONFIG_CHECKPOINT_RESTORE > > register_sysctl_paths(kern_path, pid_ns_ctl_table); > > #endif > > + > > + register_pid_ns_sysctl_table_vm(); > > return 0; > > } > [...] > > > > diff --git a/kernel/pid_sysctl.h b/kernel/pid_sysctl.h > > new file mode 100644 > > index 000000000000..90a93161a122 > > --- /dev/null > > +++ b/kernel/pid_sysctl.h > > @@ -0,0 +1,59 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef LINUX_PID_SYSCTL_H > > +#define LINUX_PID_SYSCTL_H > > + > > +#include > > + > > +#if defined(CONFIG_SYSCTL) && defined(CONFIG_MEMFD_CREATE) > > +static inline void initialize_memfd_noexec_scope(struct pid_namespace *ns) > [...] > > +static inline void register_pid_ns_sysctl_table_vm(void) > > +{ > > + register_sysctl_paths(vm_path, pid_ns_ctl_table_vm); > > +} > > +#else > > +static inline void set_memfd_noexec_scope(struct pid_namespace *ns) {} > > +static inline void register_pid_ns_ctl_table_vm(void) {} > > +#endif > [...] > > I found this patch makes build fails whne CONFIG_SYSCTL or CONFIG_MEMFD_CREATE > are not defined, as initialize_memfd_noexec_scope() and > register_pid_ns_sysctl_table_vm() are used from pid_namespace.c without the > configs protection. > > I just posted a patch for that: > https://lore.kernel.org/linux-mm/20221216183314.169707-1-sj@kernel.org/ > > Could you please check? > Hi SeongJae, Thanks for the patch ! I responded to the other thread. Andrew, >From a process point of view, should I update this patch to V9 to include the fix ? or add a patch directly on top in the mm-unstable branch. Thanks Jeff > > Thanks, > SJ