netdev - Re: Fwd: a Great Idea - include Kademlia networking protocol in kernel -- REVISITED

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]

Message-ID: <AANLkTinSCz_VZFr=52wOqSfkz-fJfo=1OHSqSvEuZKV-@mail.gmail.com>
Date:	Mon, 15 Nov 2010 05:55:33 -0500
From:	Chris Snook <chris.snook@...il.com>
To:	Marcos <stalkingtime@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	Stephen Guerin <stephen@...omplex.org>
Subject: Re: Fwd: a Great Idea - include Kademlia networking protocol in
 kernel -- REVISITED

On Sun, Nov 14, 2010 at 4:14 AM, Marcos <stalkingtime@...il.com> wrote:
>> I have no idea why and how kademlia would be added to "linux kernel"
>>
>> Its a protocol based on UDP, and probably already done on userland.
>>
>> What am I missing ?
>
> The idea is to tightly couple it to the operating system to create a
> sort of "super operating system" that is seamless to the application
> layers above.  Just like memory stores are tightly integrated as to be
> unnoticeable....

According to Google, you're not an experienced kernel developer, so
let me explain what happens when you take userspace code and implement
it in the kernel:

1) You restrict development of the feature to a specialized subset of C only.
2) You lose the simple filesystem interface enjoyed by userspace.
3) You lose the simple memory allocation enjoyed by userspace.
4) You lose the BSD network socket interface enjoyed by userspace.
5) You lose the ability to call recursive functions such as quicksort.
6) You lose the ability to call nearly every library ever written.
7) You freeze your ABI, making it much more difficult to fix your
mistakes without breaking huge amounts of userspace code, which pisses
off users, though they'll also be pissed if you *don't* fix your
mistakes.
8) You make debugging 10x harder.
9) You piss off your users 100x more when it breaks.
10) You make any security holes in your code 1000x worse.

There are plenty more drawbacks, but I think I've made the point.  We
don't put things in the kernel unless userspace is inadequate.  In
fact, we've done a lot of work over the years to provide kernel
infrastructure to allow us to move things *out* of the kernel and into
userspace.  If you think this feature would benefit from
filesystem-level integration, try implementing it as a FUSE module.
At least then you'll be able to use libraries and the language of your
choice.  None of the drawbacks of FUSE relative to the core kernel
apply in this case, so if it doesn't work with FUSE, it certainly
won't work in the kernel.

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