linux-kernel - Re: Wrapping EXPORT_SYMBOL_GPL symbols and re-exporting the wrappers with EXPORT

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] [day] [month] [year] [list]

Message-ID: <87hagdz6ug.fsf@nemi.mork.no>
Date:	Tue, 02 Jul 2013 10:47:19 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	richard -rw- weinberger <richard.weinberger@...il.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: Wrapping EXPORT_SYMBOL_GPL symbols and re-exporting the wrappers with EXPORT_SYMBOL

richard -rw- weinberger <richard.weinberger@...il.com> writes:
> On Mon, Jul 1, 2013 at 11:38 PM, Borislav Petkov <bp@...en8.de> wrote:
>> On Mon, Jul 01, 2013 at 03:32:27PM +0200, Bjørn Mork wrote:
>>> I just got a new wireless router and stumbled across an odd set of
>>> out-of-tree modules, where two GPL licensed modules were used by a third
>>> proprietary licensed one.
>>>
>>> The nice router vendor sent me the GPL'd source code, and as expected
>>> the GPL modules are little more than wrappers working around the
>>> EXPORT_SYMBOL_GPL restrictions.  Here's a complete example of one of
>>> them:
>>
>> I'm wondering if we could fail building modules which do EXPORT_SYMBOL.
>
> Then vendors will do a s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g on the kernel.
> Recently I've identified such a case.

Well, in this particular case I don't think that would happen.  I
believe the router vendor is actually trying their best to comply with
the GPL.  They have a well documented and working way to request full
source, and the source I received seems complete and matching the latest
firmware version (as requested).

I believe they are unware of this issue in a minor software component
they have obviously bought from a 3rd party, sold as a SDK with a few
standalone kernel modules . I do believe the router vendor would have
refused if this software required any modifications to the kernel.  I
believe the same goes for the SoC vendor which of course is responsible
for most of the firmware, including the kernel.

> Bjørn, please post this on legal@...ts.gpl-violations.org too.

Done.

Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/