feature request - why not make netif_rx() a pointer?

feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

Non GPL modules that want to attach themselves between all L2 drivers and
upper layers would not have to incur a performance loss if netif_rx() is
made a
pointer instead of a function (whether or not NET filters are compiled in
the kernel).
Currently control can be easily wrested from netif_rx() and others through
injection of a few instructions into the running kernel (SMC - self
modifying code)
but decreased performance is one sad consequence. Architecture specific
maintenance of SMC slows down portability, too.
The following suggestion would lead to the least amount of modifications.

The global variable "int (*netif_rx)(struct sk_buff *) = &default_netif_rx;"
gets initialized to the address of a function whose body is the default
implementation.
Drivers calling netif_rx explicitly need to be able to see the prototype
"extern int (*netif_rx)(struct sk_buff *);" or else blow up.
No further changes would be necessary because the current 200+ explicit
references
to "netif_rx(skb);"  become a poorly written "(*netif_rx)(skb);" call.
S.N.

Re: feature request - why not make netif_rx() a pointer?

[Matti Aarnio]

On Tue, Oct 22, 2002 at 05:01:53PM -0400, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a pointer instead of a function (whether or not NET filters are
> compiled in the kernel).
> Currently control can be easily wrested from netif_rx() and others through
> injection of a few instructions into the running kernel (SMC - self
> modifying code) but decreased performance is one sad consequence.
> Architecture specific maintenance of SMC slows down portability,
> too.
> The following suggestion would lead to the least amount of modifications.

  ftp://zmailer.org/linux/netif_rx.patch

  Done for 2.3.99-pre7-3  but should be easy to port to 2.5.x ...

> S.N.

/Matti Aarnio

Re: feature request - why not make netif_rx() a pointer?

[Alan Cox]

On Tue, 2002-10-22 at 22:01, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is

You could of course write GPL code 8)

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Tue, 2002-10-22 at 14:01, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a

What you are suggesting can only result in illegal binary-only
modules.

If you override netif_rx(), you are by definition implementing a derived
work of the kernel reimplementing core functionality, thus your binary
only driver is not abiding by the GPL and you are on very shaky legal
ground.

It isn't exported for a reason, there is legitimate use of it from
modules.

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
>   ftp://zmailer.org/linux/netif_rx.patch

Please EXPORT_GPL this, if you are going to do it at all.

Only non-GPL compliant binary-modules can result from this
change.

People can easily do things like implement their own entire
networking stack with this hook, which is not what we want nor
is it allowed.

Re: feature request - why not make netif_rx() a pointer?

[Ben Greear]

David S. Miller wrote:
> On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
> 
>>  ftp://zmailer.org/linux/netif_rx.patch
> 
> 
> Please EXPORT_GPL this, if you are going to do it at all.
> 
> Only non-GPL compliant binary-modules can result from this
> change.
> 
> People can easily do things like implement their own entire
> networking stack with this hook, which is not what we want nor
> is it allowed.

Don't assume we all want what you want.

As for allowed, it can
be worked around fairly easily by removing all protocol handlers and
then registering only yourself as the proprietary protocol handler,
and gobble all packets.  Sure, it's a bit of a kludge, and will have
the various crufts (like the gettimeofday code) in there, but it
will basically allow you to replace the entire stack.

If I'm right about that, then what is the difference between replacing
the stack like that and replacing the netif_rx method entirely?

Ben


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


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: feature request - why not make netif_rx() a pointer?

[Jeff Garzik]

David S. Miller wrote:
> On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
> 
>>  ftp://zmailer.org/linux/netif_rx.patch
> 
> 
> Please EXPORT_GPL this, if you are going to do it at all.



ug :(   Can we please have this not be in the fast path.  Thanks.

Make netif_rx_ the pointer, don't slow down my net drivers further...

	Jeff

Re: feature request - why not make netif_rx() a pointer?

[Jean Tourrilhes]

Slavcho Nikolov wrote :
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a
> pointer instead of a function (whether or not NET filters are compiled in
> the kernel).
> Currently control can be easily wrested from netif_rx() and others through
> injection of a few instructions into the running kernel (SMC - self
> modifying code)

	Assuming that every L2 is Ethernet and every L3 is IP ?
	Well, I've got news for you : IrDA drivers are using
netif_rx() to pass IrLAP frames to the IrDA stack, and 802.11 driver
in the future will pass 802.11 frames to the 802.2 LLC layer via
netif_rx().
	Please don't do that, I don't want people breaking the IrDA
stack in weird ways just because some random clueless code hijacked
netif_rx(). Use netfilters, or define your own private protocol/packet
type to do what you want.

	Regards,

	Jean

Re: feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
ethernet and I definitely cannot know in advance that every L3 is IP.
Nor can the assumption be made that netfilter has been built into the
kernel.
If I define my own private protocol handler (to catch all), I see cloned
skb's
which is not what I want. I tried that and dropped each one of them in the
handler, yet traffic continued to flow unimpeded (so I must have dropped
clones).
As for GPL, I hope that commercial enterprises be allowed to utilize
business models
which do not necessarily consist in providing services around free software.
The more replaceable hooks you provide to filesystems and network stacks,
the better.
S.N.


| Assuming that every L2 is Ethernet and every L3 is IP ?
| Well, I've got news for you : IrDA drivers are using
| netif_rx() to pass IrLAP frames to the IrDA stack, and 802.11 driver
| in the future will pass 802.11 frames to the 802.2 LLC layer via
| netif_rx().
| Please don't do that, I don't want people breaking the IrDA
| stack in weird ways just because some random clueless code hijacked
| netif_rx(). Use netfilters, or define your own private protocol/packet
| type to do what you want.

Re: feature request - why not make netif_rx() a pointer?

[Chris Friesen]

Slavcho Nikolov wrote:


> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

I don't think you understand the nature of the GPL and linux development.

The kernel developers do not have any obligation to anything other than 
technical excellence.  You're getting a highly optimized operating 
system *at no financial cost*.  In return, the community requires that 
certain types of modifications be made publicly available.

If you want to replace the messaging code, make a GPL'd kernel patch and 
make it available to your clients (of course they can then publish it 
all over the place if they so desire).  If those terms are not 
acceptable, there's always BSD.

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

"David S. Miller" <davem@rth.ninka.net> writes:

>On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
>>   ftp://zmailer.org/linux/netif_rx.patch

>Please EXPORT_GPL this, if you are going to do it at all.

>Only non-GPL compliant binary-modules can result from this
>change.

>People can easily do things like implement their own entire
>networking stack with this hook, which is not what we want nor
>is it allowed.

You will never understand, that <insert evil vendor here> can simply
add this modification to the kernel source ("vendor tree"), give this
source away under GPL license and then ship its binary kernel modules
with the source tree.

You won't be able to stop anyone doing this "illegal" thing. But you
hinder many legal users of this.

Not putting an export into the source or exporting GPL_ONLY symbols
won't hinder anyone. Because putting the hooks into a GPL source and
then releasing the result (code + hooks) under GPL is perfectly legal.

The only result are questions on this list, why the <insert your video
card / network / hw driver here> module works under "foobar" Linux and
not with the pristine sources.

Ah and lots of patches like "please put this into the kernel so I can
use the <insert your video card / network / hw driver here> module.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Alan Cox]

On Wed, 2002-10-23 at 16:16, Henning P. Schmiedehausen wrote:
> You will never understand, that <insert evil vendor here> can simply
> add this modification to the kernel source ("vendor tree"), give this
> source away under GPL license and then ship its binary kernel modules
> with the source tree.

Thats what lawyers are for. 

> Not putting an export into the source or exporting GPL_ONLY symbols
> won't hinder anyone. Because putting the hooks into a GPL source and
> then releasing the result (code + hooks) under GPL is perfectly legal.

Not according to lawyers

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> Not putting an export into the source or exporting GPL_ONLY symbols
>> won't hinder anyone. Because putting the hooks into a GPL source and
>> then releasing the result (code + hooks) under GPL is perfectly legal.

>Not according to lawyers

"The kernel source code + hooks under GPL" definitely are.

"The kernel source code + hooks + binary modules" are doubtful, correct.

Sorry, my wording wasn't clear.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Jean Tourrilhes]

On Wed, Oct 23, 2002 at 09:39:12AM -0400, Slavcho Nikolov wrote:
> Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
> ethernet and I definitely cannot know in advance that every L3 is IP.
> Nor can the assumption be made that netfilter has been built into the
> kernel.

	So, you thing assuming a modified netif_rx is different than
assuming netfilter support ?
	Your idea is just too dangerous.

> If I define my own private protocol handler (to catch all), I see cloned
> skb's
> which is not what I want. I tried that and dropped each one of them in the
> handler, yet traffic continued to flow unimpeded (so I must have dropped
> clones).

	For this to work, you need to modify the driver. The driver
generates a private packet type or protocol, and you will be the only
to to catch it.

> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

	You can still use *BSD, Windows, VxWorks or else, which are
very capable OSes. Nobody forces you to use Linux.

> S.N.

	Jean

Re: feature request - why not make netif_rx() a pointer?

[Ben Greear]

Jean Tourrilhes wrote:
> On Wed, Oct 23, 2002 at 09:39:12AM -0400, Slavcho Nikolov wrote:
> 
>>Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
>>ethernet and I definitely cannot know in advance that every L3 is IP.
>>Nor can the assumption be made that netfilter has been built into the
>>kernel.
> 
> 
> 	So, you thing assuming a modified netif_rx is different than
> assuming netfilter support ?
> 	Your idea is just too dangerous.

If you added something like this to netif_rx, I think it would accomplish
the goals of those who want to add their own hooks.  It would probably not
please the folks who want to keep this code out for GPL/political/legal/moral
reasons.

Note that the hook basically exists already in the bridging code.  It may
be illegal for GPL reasons to assign your own method to this hook, but I'm
sure you could put up a good legal fight if you wanted to (the bridge hook
is not exported GPL)

int netif_rx(struct sk_buff *skb)
{
	int this_cpu = smp_processor_id();
	struct softnet_data *queue;
	unsigned long flags;

+#idfef EVIL_COMPANY_NETWORK_HOOK_HACK
+       if (evil_hook) {
+          int rv = evil_hook(skb);
+          if (rv) { return; /* skb was consumed by evil hook, gawd help us all */ }
+        }
+#endif

	if (skb->stamp.tv_sec == 0)
		do_gettimeofday(&skb->stamp);


> 
> 
>>If I define my own private protocol handler (to catch all), I see cloned
>>skb's
>>which is not what I want. I tried that and dropped each one of them in the
>>handler, yet traffic continued to flow unimpeded (so I must have dropped
>>clones).
> 
> 
> 	For this to work, you need to modify the driver. The driver
> generates a private packet type or protocol, and you will be the only
> to to catch it.

So, it would be ok to modify the driver to call a new hook, one that
may be over-written by proprietary code?  Otherwise, you have to write
a non-gpl driver....yuck!


Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Wed, 2002-10-23 at 06:39, Slavcho Nikolov wrote:
> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

While more hooks may be in your interest, they are not in the interest
of free software.

I really hope you have competant legal advice for the things you are
doing, because binary-only derivative works of a GPL work are illegal.

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

"David S. Miller" <davem@rth.ninka.net> writes:

>I really hope you have competant legal advice for the things you are
>doing, because binary-only derivative works of a GPL work are illegal.

No. Distributing work based on GPL code binary-only without supplying
the source and the modifications is (might be? is considered?)
illegal. This is a major difference. 

Else I'd have to delete some of the kernels running here, because I
lost the sources for these. :-) (They're still running happily).

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Thu, 2002-10-24 at 02:28, Henning P. Schmiedehausen wrote:
> Distributing work based on GPL code binary-only without supplying
> the source and the modifications is (might be? is considered?)
> illegal. This is a major difference. 

That's what I meant.

Obviouslly this guy is intending to distribute his work though :)

Re: feature request - why not make netif_rx() a pointer?

[Henning Schmiedehausen]

On Thu, 2002-10-24 at 12:15, David S. Miller wrote:
> On Thu, 2002-10-24 at 02:28, Henning P. Schmiedehausen wrote:
> > Distributing work based on GPL code binary-only without supplying
> > the source and the modifications is (might be? is considered?)
> > illegal. This is a major difference. 
> 
> That's what I meant.
> 
> Obviouslly this guy is intending to distribute his work though :)

Fine, then we're in violent agreement. :-)

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

David Miller wrote
 
| While more hooks may be in your interest, they are not in the interest
| of free software.
| 
| I really hope you have competant legal advice for the things you are
| doing, because binary-only derivative works of a GPL work are illegal.


Thanks for the heads-up. What I propose to do is NOT to re-implement
some existing linux routine by reusing all or some of its code.
That is not only illegal, it's immoral.
In other words, the new routine will not be a derivative of the old one
or some other part of the kernel.
Instead, I'll create my own (cleanroom) handler that doesn't reuse any
existing code, which in the end will either pass control to the GPL routine
being replaced or destroy the parameters and return.
I can't see how that is a violation of GPL. If it is, then hundreds of
Linux startups had better go bankrupt now instead of fighting losing 
legal battles later.
S.N.

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Thu, 2002-10-24 at 06:30, Slavcho Nikolov wrote:
> In other words, the new routine will not be a derivative of the old one
> or some other part of the kernel.
> Instead, I'll create my own (cleanroom) handler that doesn't reuse any
> existing code, which in the end will either pass control to the GPL routine
> being replaced or destroy the parameters and return.
> I can't see how that is a violation of GPL. If it is, then hundreds of
> Linux startups had better go bankrupt now instead of fighting losing 
> legal battles later.

Let me give you an example of what would be illegal.

Using this netif_rx() hook to implement a proprietary TCP stack
to replace the GPL'd one in the kernel right now.  And that is exactly
the reason I want any such netif_rx  function pointer crap to be
EXPORT_GPL

And before someone, I forget who it was, barks again, EXPORT_GPL has
no legal significance, it is merely an annotation.  Whether a symbol
is marked this way or not has no consequence on legal matters.