linux-kernel - Re: RFC: [Restatement] KBUS messaging subsystem

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:	Wed, 3 Aug 2011 23:48:26 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Tony Ibbs <tibs@...yibbs.co.uk>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	Florian Fainelli <florian@...nwrt.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Linux-embedded <linux-embedded@...r.kernel.org>,
	Tibs at Kynesim <tibs@...esim.co.uk>,
	Richard Watts <rrw@...esim.co.uk>
Subject: Re: RFC: [Restatement] KBUS messaging subsystem

Hi Tony,

Your description doesn't really explain what you want to use this
thing exactly for in userspace.

On Fri, Jul 29, 2011 at 12:48 AM, Tony Ibbs <tibs@...yibbs.co.uk> wrote:
> So why did we write it as a kernel module?
> ==========================================
> As implementors, a kernel module makes a lot of sense. Not least
> because:
>
> * It gives us a lot of things for free, including list handling,
>  reference counting, thread safety and (on larger systems)
>  multi-processor support, which we would otherwise have to write and
>  debug ourselves. This also keeps our codebase smaller.

That's not a reason to put this into the kernel, really.

> * It helps give us reliability, partly because of the code we're
>  relying on, partly because of the strictures of working in the
>  kernel, partly by shielding us from userspace.

So now instead of crashing in userspace, we crash the kernel? This
seems like a bogus argument as well.

> * It reduces message copying (we have userspace to kernel back to
>  userspace, as opposed to a userspace daemon communicating with
>  clients via sockets)

Now this sounds like a real reason but you'd have to explain why you
can't reuse existing zero-copy mechanisms like splice() and tee().

> * It makes it simple for us to tell when a message recipient has "gone
>  away", as the kernel will call our "release" callback for us.

Again, sounds like a reasonable technical requirement but doesn't
really justify putting all this code into the kernel.

> * It allows us to provide the functionality on systems without
>  requiring anything much beyond /dev and maybe /proc in userspace.

Why is this important?

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