linux-kernel - Re: [PATCH 00/11] RFC: 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:	Tue, 17 May 2011 10:50:38 +0200
From:	Florian Fainelli <florian@...nwrt.org>
To:	Jonathan Corbet <corbet@....net>
Cc:	Tony Ibbs <tibs@...yibbs.co.uk>,
	Grant Likely <grant.likely@...retlab.ca>,
	lkml <linux-kernel@...r.kernel.org>,
	"Linux-embedded" <linux-embedded@...r.kernel.org>,
	Tibs at Kynesim <tibs@...esim.co.uk>,
	Richard Watts <rrw@...esim.co.uk>
Subject: Re: [PATCH 00/11] RFC: KBUS messaging subsystem

Hello,

Sorry for this late answer.

On Tuesday 22 March 2011 20:36:40 Jonathan Corbet wrote:
> On Fri, 18 Mar 2011 17:21:09 +0000
> 
> Tony Ibbs <tibs@...yibbs.co.uk> wrote:
> > KBUS is a lightweight, Linux kernel mediated messaging system,
> > particularly intended for use in embedded environments.
> 
> I've spent a bit of time looking at this code...this isn't a detailed
> review by any stretch, more like a few impressions.
> 
> - Why kbus over, say, a user-space daemon and unix-domain sockets?  I'm
>   not sure I see the advantage that comes with putting this into kernel
>   space.

I also fail to see why this would be required. In my opininon you are trading 
the reliability over complexity by putting this in the kernel.

Most implementations (if not all) involving system-wide message delivery for 
other daemons are running in user-space. Having a daemon for message delivery 
to other kbus clients/servers does not not seem less reliable to me. If you 
had in mind that this daemon might be killed under OOM conditions, then maybe 
your whole system has an issue, issue which could be circumvented by making 
sure the messaging process gets respawned when possible (upstart like 
mechanism or such).

> 
> - The interface is ... creative.  If you have to do this in kernel space,
>   it would be nice to do away with the split write()/ioctl() API for
>   reading or writing messages.  It seems like either a write(), OR an
>   ioctl() with a message data pointer would suffice; that would cut the
>   number of syscalls the applications need to make too.
> 
>   Even better might be to just use the socket API.

Indeed, I would also suggest having a look at what generic netlink already 
provides like messages per application PID, multicasting and marshaling. If 
you intend to keep a part of it in the kernel, you should have a look at this, 
because from my experience with generic netlink, most of the hard job you are 
re-doing here, has already been done in a generic manner.

> 
> - Does anything bound the size of a message fed into the kernel with
>   write()?  I couldn't find it.  It seems like an application could
>   consume arbitrary amounts of kernel memory.
> 
> - It would be good to use the kernel's dynamic debugging and tracing
>   facilities rather than rolling your own.
> 
> - There's lots of kmalloc()/memset() pairs that could be kzalloc().
> 
> That's as far as I could get for now.
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/