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: <20150421103519.5b0de5ea@lxorguk.ukuu.org.uk>
Date:	Tue, 21 Apr 2015 10:35:19 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Richard Weinberger <richard@....at>,
	David Herrmann <dh.herrmann@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Al Viro <viro@...iv.linux.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

> On top of that, I think that someone into resource management needs to
> seriously consider whether having a broadcast send do get_user_pages
> or the equivalent on pages supplied by untrusted recipients (plural!)
> is a good idea.

Oh but its so much fun if you pass pages belonging to a device driver, or
pass bits of a GEM object thereby keeping entire graphics textures
referenced 8)

The get_user_pages stuff looks like  simple case of premature
optimisation (or I suspect pessmimisation). If bulk data goes via
memfd/splice/socket point to point as it should (or via shared memory
objects) then you don't need all the page pinning and that begins to
simplify the code a lot. Copies of small messages are cheap if not free
on most processors. Its a memcpy into a simple refcounted buffer which
gets deleted when the refcount hits zero.

(I'd argue for also looking at stuff like GEM and the dma buffers for some
of the big stuff. As we move towards more and more accelerators again
being able to pass around handles between accelerator more and more
important)

We do need something for the multicast messaging. Whether that's
supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
message queue extensions ?). There's no real IP layer reliable ordered
multicast delivery system that is low latency and lightweight because
once it hits real networks it changes from a hard problem into a
seriously hard problem because of multicast implosions and the like.

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