linux-kernel - Re: kdbus: to merge or not to merge?

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, 23 Jun 2015 17:52:29 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

On Tue, Jun 23, 2015 at 4:19 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> Can you opine as to whether you think that kdbus should be merged?  I
>> don't mean whether you'd accept a pull request that Greg may or may
>> not send during this merge window -- I mean whether you think that
>> kdbus should be merged if it had appropriate review and people were
>> okay with the implementation.
>
> So I am still expecting to merge it, mainly for a rather simple
> reason: I trust my submaintainers, and Greg in particular. So when a
> major submaintainer wants to merge something, that pulls a *lot* of
> weight with me.

Then I'll try to review the parts that I can review, time permitting,
in the event that someone sends a clean, reviewable set of patches.
Preferably not during the merge window.

If my, or anyone else's, review uncovers an ABI issue, then I will be
correspondingly grumpy now that the userspace code is slated to ship
with new systemd versions.  Because we can't actually ship a
kernel.org kernel that will fail to boot with Fedora Rawhide or Arch
AUR or whatever unless kdbus=0 is set on the kernel command line.

If someone ships an actual desktop sandbox based on kdbus custom
endpoints, I'll try to poke holes in it as usual.  I don't intend to
review that part for security in advance because I've already said my
part: I think the design is unfit for its purpose.  Given that I don't
see how one is supposed to use it in a sensible manner for sandboxing
in the first place, it's hard to evaluate whether it will do its job a
priori.

(NB: I think I may have figured out what people mean when they say
that custom endpoints are useful for sandboxes.  They might be talking
about BusPolicy= in systemd .service files.  That's a nifty feature,
but it seems rather limited and doesn't seem to me like it would be
useful for things like xdg-app.  Also, it could certainly be
implemented in userspace.)

--Andy

P.S.  I still remain unconvinced that any of the other arguments for
merging it are better than the performance argument.  But whatever.
--
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/