linux-kernel - Re: [PATCH 2/6] module: add support for 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180723111251.x2cam6bcuglr4hhz@linux-8ccs>
Date:   Mon, 23 Jul 2018 13:12:51 +0200
From:   Jessica Yu <jeyu@...nel.org>
To:     Martijn Coenen <maco@...roid.com>
Cc:     LKML <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>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Sam Ravnborg <sam@...nborg.org>, linux-kbuild@...r.kernel.org,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        USB list <linux-usb@...r.kernel.org>,
        USB Storage list <usb-storage@...ts.one-eyed-alien.net>,
        linux-scsi@...r.kernel.org,
        Linux-Arch <linux-arch@...r.kernel.org>,
        Martijn Coenen <maco@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>,
        Iliyan Malchev <malchev@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>
Subject: Re: [PATCH 2/6] module: add support for symbol namespaces.

+++ Martijn Coenen [20/07/18 17:42 +0200]:
>On Fri, Jul 20, 2018 at 4:49 PM, Jessica Yu <jeyu@...nel.org> wrote:
>> Thanks. Also, it looks like we're currently just warning (in both
>> modpost and on module load) if a module uses symbols from a namespace
>> it doesn't import. Are you also planning to eventually introduce
>> namespace enforcement?
>
>This is something I've definitely been thinking about, and was curious
>what others would think. My main concern with enforcement is that it
>will start failing to load out-of-tree modules that use newly
>namespaced symbols. On the other hand, I think those modules will need
>to be rebuilt anyway to be able to load, because the changes to struct
>kernel_symbol make them incompatible with the current kernel. That
>could be another reason for having these symbols in a special section
>(with its own struct namespaced_kernel_symbol); but on the other hand,
>it would make the module loader more complex just to facilitate
>out-of-tree drivers, and I'm not sure where the trade-off between
>those two falls.

IMO I don't think we should bend over backwards to accommodate
out-of-tree modules - modifying the module loader to recognize even
more special sections to accommodate these OOT modules would be where
we'd draw the line I think.

>> It'd be trivial to fail the module build in
>> modpost as well as reject the module on load if it uses an exported
>> symbol belonging to a namespace it doesn't import. Although, I'd go
>> with the warnings for a development cycle or two, to gently introduce
>> the change in API and let other subsystems as well as out-of-tree
>> module developers catch up.
>
>An approach like that makes sense to me. Another alternative would be
>to make it a CONFIG_ option, and let distros/etc. decide what they are
>comfortable with.

I think going forward I would prefer to have export namespaces to be a
normal and regular part of kernel API (as in, we shouldn't require a
new option for it), and that the warnings for 1-2 cycles are courteous
enough - but anyone with stronger opinions about this should speak up.

Thanks,

Jessica