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, 15 Apr 2015 10:52:37 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	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, 15. April 2015, 10:32:19 schrieb Greg Kroah-Hartman:
> On Wed, Apr 15, 2015 at 10:18:46AM +0200, Martin Steigerwald wrote:
> > Am Dienstag, 14. April 2015, 18:36:28 schrieb Andy Lutomirski:
> > > On Mon, Apr 13, 2015 at 1:22 PM, Al Viro <viro@...iv.linux.org.uk>
> > 
> > wrote:
> > > > On Mon, Apr 13, 2015 at 09:42:17PM +0200, Greg Kroah-Hartman 
wrote:
> > > >> > I remain opposed to this half thought out trash of an ABI for
> > > >> > the
> > > >> > meta-data.
> > > >> 
> > > >> You don't have to enable the metadata if you don't want to use
> > > >> it,
> > > >> it's
> > > >> an option :)
> > > > 
> > > > OK, _that_ argument needs to be stomped out.  It had been used
> > > > before,
> > > > and it was a deliberate scam.  There is no such thing as optional
> > > > kernel interface, especially when udev/dbus/systemd crowd is
> > > > nearby.
> > > > We'd been through that excuse before; remember how devtmpfs was
> > > > pushed in as "optional"?
> > > > 
> > > > This is a huge red flag.  On the level of "I need your account
> > > > information to transfer $200M you might have inherited from my
> > > > deceased client".
> > > > 
> > > > Just to recap how it went the last time around: Kay kept pushing
> > > > his
> > > > piece of code into the tree, claiming that it was optional, that
> > > > nobody who doesn't like it has to enable it, so what's the
> > > > problem?
> > > > OK, in it went.  And pretty soon udev (maintained by the same...
> > > > meticulously honorable person) had stopped working on the kernels
> > > > that didn't have that enabled.
> > > > 
> > > > We had been there before.  To paraphrase another... meticulously
> > > > honorable person, "if you didn't want something relied upon, why
> > > > have
> > > > you put it into the kernel?" Said person is on the record as
> > > > having
> > > > no problem whatsoever with adding dependencies to the bottom of
> > > > userland stack.
> > > 
> > > It appears that, if kdbus is merged, upstream udev may end up
> > > requiring
> > > it:
> > > 
> > > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.
> > > html
> > > 
> > > Grumble.
> > 
> > Honestly, I think that tightly coupling systemd and udev to certain
> > kernel versions in lock step is crap.
> 
> Where do you see that happening?
> 
> > That you require some minimum version after some reasonable time,
> > sure.
> > But in lockstep? Seriously.
> 
> Has that happened in the past?  Look at the minimum requirements of
> systemd/udev today, something like the 3.7 kernel release, many years
> old.

I refer to the linked mailing list post from Lennart as I quote here:

> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side.

Thats plenty clear, isn´t it? As soond as kdbus is merged into kernel, 
systemd will depend on it, and then… if I need to go back to older kernel, 
I have to downgrade systemd as well?

> > I certainly do not want a broken system just cause I have to load an
> > older kernel version for some reason.
> 
> No one does.  But, work with your distribution if you end up with
> something like this.  Remember, the goal is that you can always run
> newer kernels on older userspace, as that is something that we kernel
> developers can enforce.  Userspace programs have other requirements /
> communities, it's up to them to decide what their oldest kernel version
> they wish to support.  Hint, even glibc makes these kinds of
> requirements, it's nothing new at all here, so why is this even an
> issue?

Its no issue for me that systemd required kernel 3.7. But… what Lennart 
announces above regarding kdbus reads quite differently.

> > And yes, I think its good not to force just about any userspace idea
> > into the kernel.
> 
> Do you have any technical objections to the patch as proposed?

If I had, I would have written it. I explained already that I see that 
kernel developers have strong technical objections with kdbus. And that I 
think it is important to acknowledge it, instead of telling them, that the 
API is required from userspace, userspace people know what they do, and 
they should just go away with their concerns.

Thats at least how I received quite some of your responses.

Well and I raised an eyebrow on the busname matching rules and the 
capability stuff. Yet, I didn´t comment on it, cause I didn´t look at it 
in-depth. I just ask you to take those seriously who did.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ