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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 14 Aug 2019 10:34:43 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Matthias Maennich <maennich@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, maco@...roid.com,
        Android Kernel Team <kernel-team@...roid.com>, arnd@...db.de,
        geert@...ux-m68k.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>, hpa@...or.com,
        jeyu@...nel.org,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        linux-arch@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-m68k@...ts.linux-m68k.org, linux-modules@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-usb@...r.kernel.org,
        lucas.de.marchi@...il.com, Martijn Coenen <maco@...gle.com>,
        michal.lkml@...kovi.net, mingo@...hat.com, oneukum@...e.com,
        Philippe Ombredanne <pombredanne@...b.com>, sam@...nborg.org,
        Sandeep Patil <sspatil@...gle.com>, stern@...land.harvard.edu,
        tglx@...utronix.de, usb-storage@...ts.one-eyed-alien.net,
        x86@...nel.org, yamada.masahiro@...ionext.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        David Howells <dhowells@...hat.com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Dan Williams <dan.j.williams@...el.com>,
        Adrian Reber <adrian@...as.de>,
        Richard Guy Briggs <rgb@...hat.com>
Subject: Re: [PATCH v2 05/10] module: add config option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS

On Wed, Aug 14, 2019 at 5:54 AM 'Matthias Maennich' via kernel-team
<kernel-team@...roid.com> wrote:
>
> On Tue, Aug 13, 2019 at 01:15:44PM -0700, Saravana Kannan wrote:
> >On Tue, Aug 13, 2019 at 5:19 AM 'Matthias Maennich' via kernel-team
> ><kernel-team@...roid.com> wrote:
> >>
> >> If MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is enabled (default=n), the
> >> requirement for modules to import all namespaces that are used by
> >> the module is relaxed.
> >>
> >> Enabling this option effectively allows (invalid) modules to be loaded
> >> while only a warning is emitted.
> >>
> >> Disabling this option keeps the enforcement at module loading time and
> >> loading is denied if the module's imports are not satisfactory.
> >>
> >> Reviewed-by: Martijn Coenen <maco@...roid.com>
> >> Signed-off-by: Matthias Maennich <maennich@...gle.com>
> >> ---
> >>  init/Kconfig    | 14 ++++++++++++++
> >>  kernel/module.c | 11 +++++++++--
> >>  2 files changed, 23 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index bd7d650d4a99..b3373334cdf1 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -2119,6 +2119,20 @@ config MODULE_COMPRESS_XZ
> >>
> >>  endchoice
> >>
> >> +config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
> >> +       bool "Allow loading of modules with missing namespace imports"
> >> +       default n
> >> +       help
> >> +         Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
> >> +         a namespace. A module that makes use of a symbol exported with such a
> >> +         namespace is required to import the namespace via MODULE_IMPORT_NS().
> >> +         This option relaxes this requirement when loading a module.
> >
> >> While
> >> +         technically there is no reason to enforce correct namespace imports,
> >> +         it creates consistency between symbols defining namespaces and users
> >> +         importing namespaces they make use of.
> >
> >I'm confused by this sentence. It sounds like it's the opposite of
> >what the config is doing? Can you please reword it for clarify?
>
> How about:
>
>   Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
>   a namespace. A module that makes use of a symbol exported with such a
>   namespace is required to import the namespace via MODULE_IMPORT_NS().
>   There is no technical reason to enforce correct namespace imports,
>   but it creates consistency between symbols defining namespaces and
>   users importing namespaces they make use of. This option relaxes this
>   requirement and lifts the enforcement when loading a module.

That's a lot better. Especially moving the "This option relaxes..." to
the bottom. Thanks.

-Saravana

Powered by blists - more mailing lists