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: <CAA6KcBBeP9xYbVws4=RMFNA4kyrodE-R3mifhbkee-Q+jFRcoQ@mail.gmail.com>
Date:   Wed, 4 Sep 2019 09:16:07 -0700
From:   Matthew Dharm <mdharm-usb@...-eyed-alien.net>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     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>,
        Jessica Yu <jeyu@...nel.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

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?

Matt


-- 
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux