On July 31, 2020 11:53:08 PM PDT, Christoph Hellwig <h...@lst.de> wrote: >[note: private reply now to start a flame fest with the usual suspects]
[You still CCed LKML.] >On Fri, Jul 31, 2020 at 01:11:46PM -0700, j...@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. As a start, what about applying that logic specifically to out-of-tree modules? That would address the shim problem. The justification would be that in-tree modules have at least gone through some level of review on what they're exporting. (Standard disclaimer: suggesting enhancements to the symbol licensing framework should not be taken as implicit endorsement of any legitimacy for non-GPL-compatible modules.)