Re: [RFC] /dev/random for in-kernel use

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 28. April 2014, 10:23:50 schrieb Theodore Ts'o:

Hi Theodore,

> > I am not too convinced of RDRAND due to the lack of usable source code
> > (i.e. source code that I can build myself). But that is my personal taste
> > :-)
> The problem is the FIPS validation would presumably require obeying
> the SP-800A requirement for an approved entropy source, and while we
> can't audit RDRAND to satisfy ourselves that the US government hasn't
> introduced a back door, if the only purpose of the FIPS validation is
> so that people can sell into the US government market, presuambly the
> US government is OK with a potential NSA-introduced back door.  :-)

>From a US centric view, you may be right. But there are some FIPS 140-2 
aspects which are helpful in general (albeit just a minority). And for those, 
auditible code is key. Not everybody is delighted to have NSA watching. :-)
> 
> That being said, there is some FIPS compliance code in
> drivers/char/random.c, which was introduced while Matt Mackall was
> maintaining the driver, and it mystifies me, since I never thought
> /dev/random could be an approved FIPS compliant generator --- not that
> I care, since I'm not trying to sell into the US government market,
> but the FIPS compliance code is largely harmless, so I've never
> bothered to remove it.

Ok, let me demystify it, because I was the initial trigger of the code 
changes. Albeit random.c is outside of any FIPS module, NIST requires that 
even seed sources that are outside the module boundary have a so-called 
"continuous selftest" as defined in FIPS specification section 4.9.2. If the 
self test fails, the seed source must become unavailable.
> 
> > Thanks for these suggestions. Shall I take these suggestions and turn them
> > into a full patch?
> 
> Sure, go for it.
> 
> > Moreover, I read that even for in-kernel users we should use the blocking
> > pool. Or shall we conceive of a third output pool, say, a kernel pool that
> > is independent of the output pools to user space? Adding such a pool more
> > or less only requires to define a new struct entropy_pool instance.
> 
> I've audited most of the in-kernel users, and most of them aren't even
> using them for a session key; they're using it for something less
> critical (e.g. ASLR, stack magic, etc.).  CIFS is perhaps the only
> place where it is generating a session key, and session key generation
> is just fine with the /dev/urandom pool.
> 
> So making all of the in-kernel users deal with a blocking interface is
> not worth it, IMHO.

Sorry, I did not make myself clear: for the purpose of the blocking behavior, 
shall we draw from blocking_pool or define a new pool used completely for this 
in-kernel blocking usage? Note, if we use the blocking_pool, any non-root user 
can stall the in-kernel operation indefinitely by simply reading /dev/random. 
As the in-kernel use for blocking random numbers would be limited, I was 
thinking about a new entropy pool that has no user space access.

I do not want to convert any existing in-kernel users of random data to use 
the new entropy pool.

Ciao
Stephan
-- 
| Cui bono? |