lkml.org 
[lkml]   [2014]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] /dev/random for in-kernel use
Date
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? |


\
 
 \ /
  Last update: 2014-04-28 17:21    [W:0.432 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site