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-next>] [day] [month] [year] [list]

Date:	Sun, 9 Aug 2015 12:00:27 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Daniel Mack <daniel@...que.org>, Tom Gundersen <teg@...m.no>,
	"Kalle A. Sandstrom" <ksandstr@....fi>,
	Borislav Petkov <bp@...en8.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Havoc Pennington <havoc.pennington@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	cee1 <fykcee1@...il.com>, David Herrmann <dh.herrmann@...il.com>
Subject: Re: kdbus: to merge or not to merge?

On Fri, Aug 07, 2015 at 06:26:31PM +0300, Linus Torvalds wrote:
> User space memory allocation is not AT ALL the same thing as kdbus.
> Kernel allocations are very very different from user allocations. We
> have reasonable, fairly tested, and generic models for handling user
> space memory allocation issues - limiting, debugging, failing, and
> handling catastrophes (ie oom). And no, even that doesn't always work
> perfectly, but at least there is a *lot* of support for it, and this
> is not some special case.

The memory in this case is a shmem file that is created by the kernel,
but on behalf of the bus client task, which will eventually own it. As
discussed with the mm developers, the same logic for accounting, OOM
handling, etc. applies to the kdbus shmem buffers, as they are written
to from the context of another task.  If this is mistaken, then yes, you
are right, and the code will have to be changed.

> This discussion has been full of kdbus people ignoring Andy saying "it
> worked with the user space version, it killed the machine with kdbus".
> And now people trying to claim the issues are the same. HELL NO.

Andy found some great bugs with regards to flooding the bus with
requests, which has not been ignored at all.  The same issue is present
in dbus today, but the kdbus code runs faster and more messages were
being sent than the current userspace dbus daemon, so the machine
becomes unresponsive easier.

The issue is with userspace clients opting in to receive all
NameOwnerChanged messages on the bus, which is not a good idea as they
constantly get woken up and process them, which is why the CPU was
pegged.  This issue should now be fixed in Rawhide for some of the
packages we found that were doing this. Maintainers of other packages
have been informed.  End result, no one has ever really tested sending
"bad" messages to the current system as all existing dbus users try to
be "good actors", thanks to Andy's testing, these apps should all now
become much more robust.

In chatting with Daniel on IRC, he is writing up a summary of how the
kdbus memory pools work in more detail, and he said he would sent that
out in a day or so, so that everyone can review.

thanks,

greg k-h

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