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]

Message-Id: <1825A697-7D60-44D0-8150-BC0E9F0DEB67@tonyibbs.co.uk>
Date:	Sun, 21 Aug 2011 14:28:39 +0100
From:	Tony Ibbs <tibs@...yibbs.co.uk>
To:	Pekka Enberg <penberg@...nel.org>
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

On 15 Aug 2011, at 12:46, Pekka Enberg wrote:

> Hi Tony,

Hi. Thanks for your reply

> On Sun, Aug 7, 2011 at 11:24 PM, Tony Ibbs <tibs@...yibbs.co.uk> wrote:
>> Real examples of usage that aren't the STB are a bit difficult to give
>> because they belong to customer projects that we're not allowed to
>> talk about.
> 
> That's part of the problem, I suppose. We usually don't merge new
> kernel facilities unless we're able to understand (and see) real
> applications that need them.

I understand. It is a bit of a chicken-and-egg problem.

> On Sun, Aug 7, 2011 at 11:24 PM, Tony Ibbs <tibs@...yibbs.co.uk> wrote:
>> I assume the real point of your post is that I wrote about the reasons
>> why we made KBUS a kernel module, but did not really address the
>> reasons why KBUS might want to be a kernel module in general usage.
> 
> I simply don't see a convincing argument why existing IPC and other
> kernel mechanisms are not sufficient to implement what you need. I'm
> sure there is one but it's not apparent from your emails.

Our major concern, strongly based on experience, is that given the
existing kernel mechanisms, users do not build robust (or even
sometimes working!) solutions for inter-process communication.

This is in large part because they do not realise (at the start) how
difficult this is to do. Especially if they want to keep it small.

The only *sure* way of solving this is to provide a mechanism that is
"always there", and that really means a solution provided by the
kernel. This needs to be at a higher level than what is currently
available, but obviously what exactly is provided is then a matter for
discussion. We'd obviously argue that KBUS hits a "sweet spot" for the
needs we perceive, given our application areas.

> The whole thing feels more like "lets put a message broker into the
> kernel" rather than set of kernel APIs that make sense. I suppose the
> rather extensive ioctl() ABI is partly to blame here.

I'm not sure what you mean by "message broker", except that it's
plainly meant to be a bad thing - the wikipedia meaning doesn't seem
terribly applicable to KBUS, as it covers an awful lot more territory
(mind, the discussion page is amusing).

I'll freely admit we started with the idea of what functionality we
wanted and then chose a simple-to-implement API to make it happen.

*If* KBUS were in the kernel, with its current functionality, what API
would you expect? (not just "a sockety one", but what actual API?) If
one recasts as a sockety API, how is many new socket options better
than a set of ioctls? (or is that just one of those questions to which
the answer is "well, it is"?)

> I'm not saying you need to implement everything in userspace but I'm
> also not convinced we want _all of this_ in the kernel.

That's quite understandable. So, given the functionality we want, what
would you put in the kernel, and what in userspace? (I'm personally
sceptical about how much can be split this way, but still)

(I realise that both this and the previous question are asking you to
do work, but I'm honestly hoping that even if KBUS-as-is is not
applicable, we might figure out an irreducible set of higher level
constructs than those which are currently present which will attack
the problem we wrote KBUS to attack.)

Tibs

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