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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1608909.Hzt9NDh2yO@merkaba>
Date:	Wed, 29 Apr 2015 17:27:59 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	Harald Hoyer <harald@...hat.com>
Cc:	John Stoffel <john@...ffel.org>, Havoc Pennington <hp@...ox.com>,
	Theodore Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Lukasz Skalski <l.skalski@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Am Mittwoch, 29. April 2015, 14:47:53 schrieb Harald Hoyer:
> We really don't want the IPC mechanism to be in a flux state. All tools
> have to fallback to a non-standard mechanism in that case.
> 
> If I have to pull in a dbus daemon in the initramfs, we still have the
> chicken and egg problem for PID 1 talking to the logging daemon and
> starting dbus.
> systemd cannot talk to journald via dbus unless dbus-daemon is started,
> dbus cannot log anything on startup, if journald is not running, etc...

Do I get this right that it is basically a userspace *design* decision 
that you use as a reason to have kdbus inside the kernel?

Is it really necessary to use DBUS for talking to journald? And does it 
really matter that much if any message before starting up dbus do not 
appear in the log? /proc/kmsg is a ring buffer, it can still be copied over 
later.

I remember this kind of reason not not having cgroup management in a 
separate process, but these are both in userspace.

"We have done it this way in userspace, thus this needs to be in kernel" 
doesn´t sound quite convincing to me as an argument for having dbus inside 
the kernel. Userspace uses the API the kernel and glibc provide, yes, it 
makes sense to look at what userspace needs, but designing some things in 
userspace and then requiring support for these design decisions in the 
kernel just doesn´t sound quite right to me.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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/