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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2015 22:56:40 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>, gnomes@...rguk.ukuu.org.uk,
	teg@...m.no, jkosina@...e.cz, luto@...capital.net,
	linux-kernel@...r.kernel.org, daniel@...que.org,
	dh.herrmann@...il.com, tixxdz@...ndz.org
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Thu, Apr 23, 2015 at 09:14:33PM +0200, Greg Kroah-Hartman wrote:
> I don't know what O(256) means here, O notation usually is used to
> show the complexity of a function, so this really is almost always the
> same amount of time, based on using the hash function.

This is iterating over 256 hash buckets. So O(n) complexity. Better?

> Yes, these looks like a lot of stuff but it's still really fast.

"really fast" - that's the right way to quantify things, right? Let me
reply in your terms: "no, it is dumb and slow".

> And we need it.

*Of* *course* you need it, what else. Lemme guess: there's no other
way to do this than the way it was done now, right? And we should stop
asking such stupid questions and accept it... Yeah, of course.

> Hm, this seems to be to be O(1), pretty constant, we do the same amount
> of work all the time.

The same *pile* of unnecessary and needless work. You go and collect
*all* that data on *every* packet send?!

How many packets per second are we talking here? 100, 1000, 10000...?

Let's say you're "really fast" because you've bought a "bigger machine"
and do that information collection per packet for, say 10 microseconds
(I'm probably too generous here but whatever).

So at peak rates of 10000 packets per second, and 10µs preparation time
per packet, you're wasting 100000 µs == 100 msec, i.e. 1/10th of a
second you're busy only with sending packets.

Hmm, but then the receiving side needs CPU time too...

Oh yeah, and then those pesky userspace processes need some CPU time
too...

Are you really serious or is this some tactic of deliberately asking
dumb questions? Let me know now so that I can stop wasting my time.

> I don't understand what a token provides that is different from what is
> happening here, please explain.  How can that be faster than what we do
> today?

A token-based scheme would give you significantly less traffic;
distributing those in sandboxing, containers, etc for free and you can
throw the metadata collecting in the garbage can:

Example:

* A daemon issues a token, say, a capability to reboot.

* It gives that token (with the kernel as intermediary) to a recipient
  which should be allowed to reboot.

* recipient can drop privileges, run in a sandbox, whatever, it still
  has that token.

That's exactly one packet sent *without* any information collection.
Recipient has to authenticate itself to the kernel when requesting the
packet.

Clean and simple.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/