linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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:	Mon, 20 Apr 2015 23:16:49 +0200
From:	Richard Weinberger <richard@....at>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	David Herrmann <dh.herrmann@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Al Viro <viro@...iv.linux.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Greg,

Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
>> In which situation on a common Linux system is the current dbus too slow today?
>> I've never seen a issue like "Oh my system is slow because dbus is
>> eating too much CPU cycles".
> 
> See the original email which explained all of the things we can not do
> with D-Bus, some of which are due to speed, that can now be done with the
> kdbus code.

okay, let's do it together.

1. Performance
You write:
"DBus is not used for performance sensitive applications because DBus is slow.
We want to make it fast so we can finally use it for low-latency,
high-throughput applications."

Which applications exactly?
This reads to me like a solution for a non-existing problem.

2. Security
I don't think that you need a 13k piece of code in the kernel to solve
that issue.

3. Semantics for apps with heavy data payloads

Again, sounds like a solution for a non-existing problem.

4. "Being in the kernel closes a lot of races which can't be fixed with
   the current userspace solutions."

You really need a in-kernel dbus with 13k to solve that?

5. Eavesdropping on the kernel level

Same here.

6. dbus-daemon is not available during early-boot or shutdown.

Why do you need dbus in that stage?

Can you now please start answering questions instead of pointing to random mails?

>> dbus my have issues which are worth to fix. But moving dbus more or
>> less in the kernel
>> seems overkill.
> 
> Why do you think so?  How is this code "overkill"?

Did you try to review it? ;-)
No really, it is by means no IPC primitive it is a super high level
in-kernel IPC and not trivial.

>> So, what exactly are these issues and why can't we add new IPC
>> primitives to Linux which
>> allow a decent userland dbus?
> 
> That's exactly what this patchset does.

No, it moves dbus into the kernel.

>> To me kdbus seems much like an ad-hoc solution which is very dbus centric.
> 
> Yes it is, but the "dbus centric" thing is a valid model that is quite
> useful and in use by a lot of programs as it solves a real problem.

What programs?

>> IIRC Alan asked the same question.
> 
> Yes, you can build everything off of tiny socket calls, but when you do
> that, you end up with the D-Bus userspace implementation we have today,
> with the issues that it has.  By moving portions of that model into the
> kernel, as is done here, it solves a number of these issues, and allows
> for a lot more flexibility and things to be done that are impossible
> with the current model of trying to build on top of tiny ipc functions.
> 
> The existing code is much stripped down from what you think of as a
> D-Bus daemon today, only the exact needed pieces are implemented here.
> 
> Do you see anything wrong with the code as is submitted (aside from the
> issues that Al has pointed out that are being resolved already?)

The code is fine, the concepts are fishy as pointed out many times in this thread.
My point is that we should try hard to fix dbus instead of moving it into the kernel.

Thanks,
//richard
--
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/