netdev - Re: [RFC, PATCH 2.6.29.2] Ethernet V2.0 Configuration Testing Protocol, revision 20090428

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

Date:	Thu, 30 Apr 2009 19:06:44 +0930
From:	Mark Smith 
	<lnx-netdev@...22607b6285f9c5d5ea31ea9d8a7ac.nosense.org>
To:	David Miller <davem@...emloft.net>
Cc:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [RFC, PATCH 2.6.29.2] Ethernet V2.0 Configuration Testing
 Protocol, revision 20090428

Hi David,

On Wed, 29 Apr 2009 14:35:34 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:

> From: Mark Smith <lnx-netdev@...22607b6285f9c5d5ea31ea9d8a7ac.nosense.org>
> Date: Thu, 30 Apr 2009 06:59:50 +0930
> 
> > So should I submit patches that rip every protocol out of the kernel
> > that could be implemented in user space using AF_PACKET?
> 
> Don't be rediculious.
> 

I'm sorry about that. That's probably an Australian thing to do when
you seem to be encountering what appears to be an obvious
inconsistency. 

> The deciding factor is actually one of performance.
> 
> And I can't see how putting this into userspace makes it any less
> usable, performance wise.  Whereas for protocols that we do have in
> the kernel, performance does matter.
> 

I understand that, for all protocols where performance is critical.
What I don't understand though is why an IPv4 Echo Request responder,
an IPv6 Echo Request responder and an 802.2/LLC TEST frame responder
are in the kernel. I've never heard of anybody saying these specific
testing functions are performance critical. If they are, I'm genuinely
interested in what the performance critical cases are.

In my opinion, the primary reason why these sorts of testing functions
have been put in kernels rather than user space is to ensure ubiquity.
If they weren't universally available, then you could never be sure
what a lack of response ment - it could either mean the network
connectivity is truely broken, the user space daemon isn't
running, or the protocol hasn't been implemented. The user space daemon
might not be running because it has failed, or because it has been
switched off. The results of your testing are far more ambiguous,
making these tests significantly less useful.

Admittedly this confusion is already now happening more often, because
people are firewalling IPv4 ping. People who have to troubleshoot
networks now have to spend more time and develop different and more
complicated tests to verify basic remote node availability. I used to
be able to rely on a ping test from a router to an locally attached
host, now if I don't get a response to a ping, I now have to check the
ARP cache as well, to verify if the host is actually there or not. Not
a big additonal amount of time in itself, but multipled by all the
network admins out there, it'd be a significant time cost.

> Stephen is right, this protocol could very well be more appropriately
> implemented in userspace.

So that raises a hypthetical question. If I were to develop user space
implementations of an IPv4 ping responder, an IPv6 responder, and an
802.2/LLC TEST responder, would patches to remove those functions from
the kernel be accepted?

Thanks,
Mark.
--
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