netdev - Re: [RFC PATCH 00/30] Kernel NET policy

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]

Message-ID: <20160718194357.GL5871@two.firstfloor.org>
Date:	Mon, 18 Jul 2016 12:43:57 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Florian Westphal <fw@...len.de>,
	kan.liang@...el.com, davem@...emloft.net,
	linux-kernel@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
	netdev@...r.kernel.org, jeffrey.t.kirsher@...el.com,
	mingo@...hat.com, peterz@...radead.org, kuznet@....inr.ac.ru,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
	akpm@...ux-foundation.org, keescook@...omium.org,
	viro@...iv.linux.org.uk, gorcunov@...nvz.org,
	john.stultz@...aro.org, aduyck@...antis.com, ben@...adent.org.uk,
	decot@...glers.com, jesse.brandeburg@...el.com
Subject: Re: [RFC PATCH 00/30] Kernel NET policy

> I wonder if this can be attacked from a different angle. What would be
> missing to add support for this in user space? The first possibility
> that came to my mind is to just multiplex those hints in the kernel.

"just" is the handwaving part here -- you're proposing a micro kernel
approach where part of the multiplexing job that the kernel is doing
is farmed out to a message passing user space component.

I suspect this would be far more complicated to get right and
perform well than a straight forward monolithic kernel subsystem --
which is traditionally how Linux has approached things.

The daemon would always need to work with out of date state
compared to the latest, because it cannot do any locking with the
kernel state.  So you end up with a complex distributed system with multiple
agents "fighting" with each other, and the tuning agent
never being able to keep up with the actual work.

Also of course it would be fundamentally less efficient than
kernel code doing that, just because of the additional context
switches needed.

-Andi