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]

Date:	Wed, 15 Apr 2015 11:28:36 +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, 11:02:12 schrieb Greg Kroah-Hartman:
> > > > 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.
> 
> I take technical comments very seriously, where have I not?  If you have
> technical reasons why the current implementation has problems, please
> let me know, and I will be glad to address them.

>From what I read you basically answered all technical comments like in:

The dbus API is like it is for a very good reason, everyone is using it 
and everyone agrees. Capabilities are used in userspace for good reason 
and so on.

But I see, here, not everyone does. 

Most of your answers didn´t seem to address the concerns raised of having 
this in the *kernel*. Especially the security concerns.

Thats what I meant with "And yes, I think its good not to force just about 
any userspace into the kernel". I think arguing with this is how userspace 
does it pattern, even if it truly is for a very good reason, is not 
sufficient as argument for having it in the kernel.

I am just looking at the argumentative pattern here. If other kernel 
developers complain about how hard it is to review and wrap their mind 
around the kdbus patches… I am scared at just trying to understand the 
patches. So no technical complaints from me. I did not nack it nor do I 
see myself in the position to nack it.

So feel free to do with my argument what you like. I just tried to 
understand why the communication in here works in circles as it does and I 
think will continue to work like that as long as its the userspace does it 
that way argument or this is optional argument only. For the discussion to 
go anywhere its important to acknowledge each other.

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