Thor Lancelot Simon | 7 Nov 2011 07:22
Picon
Favicon

Patch: rework kernel random number subsystem (*nearly final*)

On Fri, Oct 21, 2011 at 05:15:55PM -0400, Thor Lancelot Simon wrote:
> 
> I have placed a patch at http://www.panix.com/~tls/rnd1.diff which
> implements many changes to the generation and use of randomness
> in the kernel (I previously sent it to these lists directly but
> it seems to be too large).
> 
> It is (most of) the first step in a three step process I envision for major
> overhaul of this subsystem:
> 
> 	1) Provide infrastructure needed to separate entropy
> 	   harvesting from random stream generation.  Clean up
> 	   interfaces between existing kernel components that
> 	   deal with random number generation and consumption.

There's a new patch at http://www.panix.com/~tls/rnd4.diff which
I intend to commit as soon as I find and fix one remaining bug.  This
version of the patch adds some infrastructure the new random/urandom
pseudodevices will need and addresses several nasty race conditions
around rekeying by changing the rndpool mutex from IPL_SOFTCLOCK to
IPL_VM.

It also fixes several miscellaneous bugs (including a severe one in
rnd_add_data that has been around for a long time) and addresses KNF
issues in my previous patches.  There are also a few performance tweaks.

The mutex change to IPL_VM should not have much performance impact as
it's never held during copy in/out and my next set of changes will
eliminate any direct access to the entropy pool (thus any taking of
the mutex) by the pseudodevices -- that is, from userspace consumers.
(Continue reading)

Jean-Yves Migeon | 29 Nov 2011 02:51
Picon

secmodel_register(9) API

Dear all,

A few weeks back I tried adding a sysctl knob to allow users to control
their CPU affinity. However, while implementing checks to restrict usage
of this sysctl, I hit a limitation regarding secmodel(9): the current
design cannot allow a secmodel to query the state/properties of other
secmodels.

So, when one wants to create sysctls that can only be changed when
securelevel is below a certain level, you end up adding more hooks to
secmodel_securelevel(9)... which is problematic, because the sysctl does
not necessarily belong to this secmodel (consider curtain and suser, as
an exemple).

elad <at>  contacted me off-list; he noticed this shortcoming a while back 
and we agreed that the secmodel_register(9) had to be extended to cope 
with this. So, after a number of mail exchanges, here's a patch.

--- CAUTION -- NOTES ---

All consumers of the secmodel(9) API should now use the 
secmodel_register(9) API to register a secmodel(9). Otherwise, you can 
end up with a system without any secmodel registered. Kauth(9) listeners 
will work as usual, but a DEFER decision with no registered secmodel is 
equivalent to ALLOW.

--- Explanations ---

This API allows any secmodel(9) to register callbacks that can be used 
later on for cross-secmodel "safe" communication.
(Continue reading)


Gmane