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:	Thu, 21 Feb 2013 09:19:33 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	David Miller <davem@...emloft.net>
CC:	stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: why is it not allowed to add a new socket protocol family as
 an external module?

On 02/20/2013 07:05 PM, David Miller wrote:
> From: Chris Friesen<chris.friesen@...band.com> Date: Wed, 20 Feb 2013
> 18:44:50 -0600
>
>> On 02/20/2013 05:23 PM, Stephen Hemminger wrote:
>>> On Wed, 20 Feb 2013 10:56:13 -0600 Chris
>>> Friesen<chris.friesen@...band.com>   wrote:
>>>
>>>> Hi,
>>>>
>>>> I was just wondering why the kernel doesn't allow a new
>>>> network protocol family to be loaded as as a kernel module
>>>> built outside the kernel source tree.
>>
>>> If you want an answer, to the question, use a tool like cscope
>>> and learn to read the kernel code. There are several tables of
>>> pointers sized by NPROTO.
>>
>> That's a bit insulting, don't you think?
>
> Absolutely not insulting at all.
>
> The list is _NOT_ a place to go when you're just too damn lazy to
> take the 10 seconds it would have taken to answer your question with
> a quick NPROTO grep on the kernel sources.
>
> Stephen's response to you was therefore %100 appropriate, and I
> would have told you likewise if I had been the first to respond.

As the rest of my reply to Stephen should have made clear, I in fact did 
read the code prior to asking the question.  My question was not about 
the details of the current implementation, but rather the rationale 
behind them.

I'm fully aware that there are statically-sized tables in the current 
code, and thus the current code does not support dynamically adding 
protocols.  However, it would be reasonably straightforward to extend 
the static tables with some form of dynamic data structure to handle 
adding new network protocols at runtime.

If the current restriction is intentional (to minimize the likelihood 
of non-GPL'd network protocols, for instance), then there's no point in 
anyone submitting patches to add support for dynamic network protocols. 
  If it's just because nobody has bothered to do it yet, then it might 
be an interesting project.

Chris




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ