Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3197285rwb; Fri, 16 Dec 2022 11:22:09 -0800 (PST) X-Google-Smtp-Source: AA0mqf7W8hw5jzEm+2iWbud62yb1dnWsEtbeKeghTYj7Hjm7TIbLfmsBEeTZJTTaszMiOvHfMF79 X-Received: by 2002:a05:6a20:c6c9:b0:a3:d6:8795 with SMTP id gw9-20020a056a20c6c900b000a300d68795mr36801654pzb.17.1671218529253; Fri, 16 Dec 2022 11:22:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671218529; cv=none; d=google.com; s=arc-20160816; b=fdE+0ghcMyOMfDcZq4mkX/Ua/r/Hw8AHea343g1VhdMxK+N1aPQF+BXwXFSW0BJiIY jnt8keJDxwNJHrO3gtr35c2OJD1u25NoLZltBdvDTvjhreRGC50p4cFOtPgkPdv3GBWJ yrr665z/RQBuAyYwd4EOAK9zfUD3RZaTYkuwZRa5RTNc2PmbkFTaSb9uLlZAQ8pVbTjK QaHCyVaj6d6DcYIdiEX6Z1wMUihFDj7zvNoMsKheXuncvcQasQurwr5egF3qR/h3OF1Z eNnLn16QNGq7rMMfEK60EFWuiMIWefXiRY0dvaLd6/j5twrrnhlxrSX/a4wZU00/UM0g +sxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=t2+6atgOOmHW3Y6/BjOreIZzNs1w8s58OfIYvMq9s2c=; b=Nks9o5a+PVgf1V6hK9/LQiMJgXdB+swbpa+zUFOhA1EoiYRUoMmeNGUh3JWuQYuUe6 mvpiOhjj0GhjriR1ywg4O1/6Z3uBH60bXuS6LYwkxHadjPkZZKiuaZ9Fhr7Th2VhnZX/ No8dmeK+TMs6jI1WXh0fKyUwdRNv9MVxGhLTGpjanvR5Wt4UPdo/fl+ea1z9aCtE6sM3 SVtWKGUquVbg9rG8epMAEv9eYfDgBKryWMwUkLFjK6r5JrJzWCkAeuOQvzvaet08oBNQ 0fg+2eXQPF1b/7j44xWrfzcj2b5UaSoMWzlag6Z4djtqw5rn+58uR2qDFg0apg+o1gTJ 0SOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KBlw0Zv8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k7-20020a63d847000000b0047005e8d874si3780596pgj.9.2022.12.16.11.22.00; Fri, 16 Dec 2022 11:22:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KBlw0Zv8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231650AbiLPTDw (ORCPT + 68 others); Fri, 16 Dec 2022 14:03:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231572AbiLPTDt (ORCPT ); Fri, 16 Dec 2022 14:03:49 -0500 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3ED186A768 for ; Fri, 16 Dec 2022 11:03:45 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id x66so2413836pfx.3 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=e8mEq1Il+yjLrGTlBIMuReLO3qcXXoe8bFYfBjs1TjR5eq2sy6RM6bzbWAcdB9FHm3 izDhtTbca4GwJR+wIuw6WlgiknCLYozPcdXc+or0g+hy2aE+zSEizp5R447wCz3zYgMj 7enbYMfsSANoxOlF53qOvky3zGThpp1qVFdbufP40DTqOhcnb0DoozVPiLPGJ+yuXLqX TTZmTpSR2hYDl96CQCKommT1C6xlsLNy4YuA5Qr851PNZv5euHVzMBcS+TeAoIFog0Br 8a3+aiyNDxOQ4Ala1kQM28a82wJaUVJe+A2s8gzt/HAYLfUdxVP8Z8cE6/4skLZ+pWiE /eOg== X-Gm-Message-State: ANoB5pl0QZW18fouTAO3Ec+uBZwl+E5ma8F1lbuEx6sRQZ7Ynk1vF8Vi QeQCsVtC9eLITmlhlDe6yAzrbL/ZmLQFjk5z57Tx3g== 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-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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