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:	Tue, 21 Apr 2015 16:53:52 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Olivier Galibert <galibert@...ox.com>,
	Andy Lutomirski <luto@...capital.net>,
	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

> Um, no, they go through the kernel for that model as well, same
> interface, it just depends on the type of message that you are sending
> as to who the recipients are (single or more than one.)

In other words its bog standard classic network layer multicasting. You
don't need much policy for that

> How would packet filtering work here for this type of decision making?
> That's a much more complex interface than what we have implemented,
> don't you agree?

No - its about 10 lines of code to invoke EBPF. The socket layer supports
it today. What it doesn't have is the multicast transport bits.

It's a classic networking layer item. I know DaveM didn't like the
original because all the policy was mixed up in it and the blocking
problem was undefined but every time I look at this I reach the same
conclusion

- Its a socket layer problem
- The sk_buff structures are the memory allocator needed
- The socket layer does the resource management
- The socket layer has SCM_RIGHTS already
- The socket layer has EBPF already
- The socket layer has a fantastic debugging environment
- It's the same components needed for fast MQ services and (almost) for
  HPC uses [HPC wants scatter/gather too]

It just needs

- RDP multicast AF_UNIX type sockets. Not in itself a huge problem,
  although it does need some nice refcounting so that you queue each
  message once and the readers share it.
- A clear fairly policy-free description of how you deal with multicast
  to some clients who are "full"

And I think that aspect of things needs to go back via the networking
maintainers to figure out if this is "DaveM doesn't like dbus" or there
are some actually insoluble problems I'm missing here.

Designing alternate turds to go around DaveM may not be the right
approach even if he's stubborn 8)

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/