linux-kernel - Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG

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: <20190905104147.GA27788@linux-8ccs>
Date:   Thu, 5 Sep 2019 12:41:47 +0200
From:   Jessica Yu <jeyu@...nel.org>
To:     Matthew Dharm <mdharm-usb@...-eyed-alien.net>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Matthias Maennich <maennich@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Lucas De Marchi <lucas.de.marchi@...il.com>,
        maco@...roid.com, sspatil@...gle.com,
        Will Deacon <will@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        linux-modules@...r.kernel.org,
        linux-usb <linux-usb@...r.kernel.org>,
        USB Mass Storage on Linux 
        <usb-storage@...ts.one-eyed-alien.net>,
        linux-watchdog@...r.kernel.org
Subject: Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core
 symbols in WATCHDOG_CORE namespace

+++ Matthew Dharm [04/09/19 09:16 -0700]:
>On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> Note that I don't object to the patch set in general. There may be symbols
>> which only need be exported in the context of a single subsystem or even
>> driver (if a driver consists of more than one module). For example, a mfd
>> driver may export symbols which should only be called by its client drivers.
>> In such a situation, it may well be beneficial to limit the use of exported
>> symbols.
>
>I can appreciate this benefit.
>
>> I am not sure what good that does in practice (if I understand correctly,
>> a driver only has to declare that it wants to use a restricted use symbol
>> if it wants to use it), but that is a different question.
>
>I think this question implies that you are coming from the perspective
>of "security" or wanting to restrict access to the underlying
>functions, rather than wanting to clean-up the way symbols are handled
>for manageability / maintainability purposes (which is the goal, as I
>understand it).
>
>HOWEVER, I have one question:  If these patches are included, and
>someone wants to introduce a bit of code which needs to use two
>symbols from different namespaces but with the same name, can that be
>done?  That is, if driver A has symbol 'foo' and driver B has symbol
>'foo' (both in their respective namespaces), and driver C wants to use
>A.foo and B.foo, can that be supported?

As of now, we currently don't support this - modpost will warn if a
symbol is exported more than once (across modules + vmlinux), and the
module loader currently assumes exported symbol names are unique.  Do
you have a concrete use case? If there is a strong need for this, I
don't think it'd be too hard to implement.

Thanks,

Jessica