lkml.org 
[lkml]   [2020]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: inherit TAINT_PROPRIETARY_MODULE v2
[note: private reply now to start a flame fest with the usual suspects]

On Fri, Jul 31, 2020 at 01:11:46PM -0700, josh@joshtriplett.org wrote:
> 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.)

I'd personally 100% agree with that, but I'd rather clear it with Linus
privately first. This would basically make most of the usual
modular subsystems unavailable to proprietary modules as all of them
use _GPL driver core exports, and I suspect he'd cave into the screaming.

\
 
 \ /
  Last update: 2020-08-01 08:54    [W:0.118 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site