linux-kernel - Re: inherit TAINT_PROPRIETARY

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]

Message-ID: <20200731201146.GA34345@localhost>
Date:   Fri, 31 Jul 2020 13:11:46 -0700
From:   josh@...htriplett.org
To:     Christoph Hellwig <hch@....de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jessica Yu <jeyu@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: inherit TAINT_PROPRIETARY_MODULE v2

Christoph Hellwig wrote:
> we've had a bug in our resolution of _GPL modules since day one, that
> is a module can claim to be GPL licensed and use _GPL exports, while
> it also depends on symbols from non-GPL modules.  This is used as a
> circumvention of the _GPL exports by using a small shim module using
> the _GPL exports and the other functionality.

This looks great. You might also consider doing the reverse: if a module
imports any EXPORT_SYMBOL_GPL symbols, any symbols that module in turn
exports shouldn't be importable by any module that doesn't explicitly
claim to be GPL-compatible. Effectively, if a module imports any
EXPORT_SYMBOL_GPL symbols, all of its exported symbols would then be
treated as EXPORT_SYMBOL_GPL.

This would catch the case of attempting to "wrap" EXPORT_SYMBOL_GPL
symbols in the other direction, by re-exporting the same or similar
functions to another module. (This would help catch mistakes, not just
intentional malice.)

- Josh Triplett