linux-kernel - Re: namespace support requires network modules to say "GPL"

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]

Date:	Mon, 03 Dec 2007 10:19:02 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Patrick McHardy <kaber@...sh.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Mark Lord <lkml@....ca>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, containers@...ts.osdl.org
Subject: Re: namespace support requires network modules to say "GPL"

Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
>
>   
>> Ben Greear wrote:
>>     
>>> I have a binary module that uses dev_get_by_name...it's sort of a bridge-like
>>> thing and
>>> needs user-space to tell it which device to listen for packets on...
>>>
>>> This code doesn't need or care about name-spaces, so I don't see how it could
>>> really
>>> be infringing on the author's code (any worse than loading a binary driver
>>> into the kernel
>>> ever does).
>>>       
>
> Regardless of infringement it is incompatible with a complete network
> namespace implementation.  Further it sounds like the module you are
> describing defines a kernel ABI without being merged and hopes that
> ABI will still be supportable in the future.  Honestly I think doing so
> is horrible code maintenance policy.
>   
I don't mind if the ABI changes, so long as I can still use something 
similar.

The namespace logic is interesting to me in general, but at this point I 
can't think of a way that
it actually helps this particular module.  All I really need is a way to 
grab every frame
from eth0 and then transmit it to eth1.  I'm currently doing this by 
finding the netdevice
and registering a raw-packet protocol (ie, like tcpdump would do).  At 
least up to 2.6.23,
this does not require any hacks to the kernel and uses only non GPL 
exported symbols.

Based on my understanding of the namespace logic, if I never add any 
namespaces,
the general network layout should look similar to how it does today, so 
I should have
no logical problem with my module.

> Once things are largely complete it makes sense to argue with out of
> tree module authors that because they don't have network namespace
> support in their modules, their modules are broken.   
>   
Does this imply that every module that accesses the network code *must* 
become
GPL simply because it must interact with namespace logic that is 
exported as GPL only symbols?

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com> 
Candela Technologies Inc  http://www.candelatech.com


--
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/