linux-kernel - Re: [PATCH 5/6] mm: Kconfig: make config SECRETMEM visible with EXPERT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAS_u_BkcQ4A34ENdSy=J9KOpgzHS6NSXkGBiVy_7CqPFQ@mail.gmail.com>
Date:   Fri, 9 Sep 2022 15:22:43 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Mike Rapoport <rppt@...ux.ibm.com>
Cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Peter Chen <peter.chen@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb <linux-usb@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/6] mm: Kconfig: make config SECRETMEM visible with EXPERT

On Thu, Sep 8, 2022 at 8:24 PM Mike Rapoport <rppt@...ux.ibm.com> wrote:
>
> On Thu, Sep 08, 2022 at 12:43:36PM +0200, Lukas Bulwahn wrote:
> > Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
> > introduces CONFIG_EXPERT to carry the previous intent of CONFIG_EMBEDDED
> > and just gives that intent a much better name. That has been clearly a good
> > and long overdue renaming, and it is clearly an improvement to the kernel
> > build configuration that has shown to help managing the kernel build
> > configuration in the last decade.
> >
> > However, rather than bravely and radically just deleting CONFIG_EMBEDDED,
> > this commit gives CONFIG_EMBEDDED a new intended semantics, but keeps it
> > open for future contributors to implement that intended semantics:
> >
> >     A new CONFIG_EMBEDDED option is added that automatically selects
> >     CONFIG_EXPERT when enabled and can be used in the future to isolate
> >     options that should only be considered for embedded systems (RISC
> >     architectures, SLOB, etc).
> >
> > Since then, this CONFIG_EMBEDDED implicitly had two purposes:
> >
> >   - It can make even more options visible beyond what CONFIG_EXPERT makes
> >     visible. In other words, it may introduce another level of enabling the
> >     visibility of configuration options: always visible, visible with
> >     CONFIG_EXPERT and visible with CONFIG_EMBEDDED.
> >
> >   - Set certain default values of some configurations differently,
> >     following the assumption that configuring a kernel build for an
> >     embedded system generally starts with a different set of default values
> >     compared to kernel builds for all other kind of systems.
> >
> > Considering the second purpose, note that already probably arguing that a
> > kernel build for an embedded system would choose some values differently is
> > already tricky: the set of embedded systems with Linux kernels is already
> > quite diverse. Many embedded system have powerful CPUs and it would not be
> > clear that all embedded systems just optimize towards one specific aspect,
> > e.g., a smaller kernel image size. So, it is unclear if starting with "one
> > set of default configuration" that is induced by CONFIG_EMBEDDED is a good
> > offer for developers configuring their kernels.
> >
> > Also, the differences of needed user-space features in an embedded system
> > compared to a non-embedded system are probably difficult or even impossible
> > to name in some generic way.
> >
> > So it is not surprising that in the last decade hardly anyone has
> > contributed changes to make something default differently in case of
> > CONFIG_EMBEDDED=y.
> >
> > Currently, in v6.0-rc4, SECRETMEM is the only config switched off if
> > CONFIG_EMBEDDED=y.
> >
> > As long as that is actually the only option that currently is selected or
> > deselected, it is better to just make SECRETMEM configurable at build time
> > by experts using menuconfig instead.
> >
> > Make SECRETMEM configurable when EXPERT is set and otherwise default to
> > yes. Further, SECRETMEM needs ARCH_HAS_SET_DIRECT_MAP.
> >
> > This allows us to remove CONFIG_EMBEDDED in the close future.
> >
> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@...il.com>
>
> Acked-by: Mike Rapoport <rppt@...ux.ibm.com>
>
> > ---
> >  mm/Kconfig | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index ceec438c0741..aa154c20b129 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -1068,7 +1068,13 @@ config IO_MAPPING
> >       bool
> >
> >  config SECRETMEM
> > -     def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
> > +     default y
> > +     bool "Enable memfd_secret() system call" if EXPERT
> > +     depends on ARCH_HAS_SET_DIRECT_MAP
> > +     help
> > +       Enable the memfd_secret() system call with the ability to create
> > +       memory areas visible only in the context of the owning process and
> > +       not mapped to other processes and other kernel page tables.
> >
> >  config ANON_VMA_NAME
> >       bool "Anonymous VMA name support"
> > --
> > 2.17.1
> >
>
> --
> Sincerely yours,
> Mike.

Reviewed-by: Masahiro Yamada <masahiroy@...nel.org>

-- 
Best Regards
Masahiro Yamada