linux-kernel - Re: [PATCH 0/6] Symbol namespaces

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 23 Jul 2018 16:28:41 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Martijn Coenen <maco@...roid.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>, Jessica Yu <jeyu@...nel.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Martijn Coenen <maco@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>, malchev@...gle.com,
        Joel Fernandes <joelaf@...gle.com>
Subject: Re: [PATCH 0/6] Symbol namespaces

On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen <maco@...roid.com> wrote:
> As of Linux 4.17, there are more than 30000 exported symbols
> in the kernel. There seems to be some consensus amongst
> kernel devs that the export surface is too large, and hard
> to reason about.
>
> Generally, these symbols fall in one of these categories:
> 1) Symbols actually meant for drivers
> 2) Symbols that are only exported because functionality is
>    split over multiple modules, yet they really shouldn't
>    be used by modules outside of their own subsystem
> 3) Symbols really only meant for in-tree use
>
> When module developers try to upstream their code, it
> regularly turns out that they are using exported symbols
> that they really shouldn't be using. This problem is even
> bigger for drivers that are currently out-of-tree, which
> may be using many symbols that they shouldn't be using,
> and that break when those symbols are removed or modified.
>
> This patch allows subsystem maintainers to partition their
> exported symbols into separate namespaces, and module
> authors to import such namespaces only when needed.
>
> This allows subsystem maintainers to more easily limit
> availability of these namespaced symbols to other parts of
> the kernel. It can also be used to partition the set of
> exported symbols for documentation purposes; for example,
> a set of symbols that is really only used for debugging
> could be in a "SUBSYSTEM_DEBUG" namespace.

This looks nice. I don't want to overload you with additional
requests, but it might be good to think about how this can
be taken further, if we want to actually convert large
parts of the kernel to it. I have two ideas:

- It would be nice to have a simple mechanism in Kconfig
  to put all symbols in a module into a namespace that is
  derived from KBUILD_MODNAME, to avoid having to
  annotate every symbol separately. This could be similar
  to how we ended up dealing with EXPORT_NO_SYMBOLS
  in the linux-2.4 days, with the goal of eventually having
  a namespace for each symbol. Similarly, we could pass
  a number of default namespaces through the Makefile,
  e.g. if we have a directory that has lots of drivers that all
  import the symbols from a common subsystem module.

- If this is possible to implement, it would be great to have
  a way to limit the globally visible symbols in a module
  to the ones that are explicitly exported  even when a that
  module is built-in rather than loadable. Not sure how this
  is best done though. A couple of things can be done with
  objcopy, or possibly by reintroducing partial linking (which
  was removed not too long ago).

        Arnd