Message-ID: <2722901.IcH4JOB8ab@tauon>
Date:	Tue, 10 Sep 2013 18:54:38 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	Theodore Ts'o <tytso@....edu>
Cc:	LKML <linux-kernel@...r.kernel.org>, dave.taht@...ferbloat.net
Subject: Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

Am Dienstag, 10. September 2013, 11:04:19 schrieb Theodore Ts'o:

Hi Theodore,

>On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
>> Hi,
>> 
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and the event value of hardware events.
>> 
>> Typically the high-resolution timer of get_cycles delivers the
>> majority of entropy, because the event value is quite deterministic
>> and jiffies are very coarse.
>> 
>> However, on the following architectures, get_cycles will return 0....
>
>I am working on this issue with the MIPS maintainers, and on all of
>the platforms where we have some kind of counter which is derived from
>the CPU cycle clock, we should use it.  So for example there is a
>register on MIPS which is incremented on every single clock cycle mod
>the number of entries in the TLB.  This isn't sufficient for
>get_cycles() in general, but what I am thinking about doing is
>defining interface random_get_fast_cycles() which can be get_cycles()
>on those platforms that have such an interface, but on platforms that
>don't we can try to do something else.

So, MIPS seem to be covered, and m68k too. But what about the number of 
other platforms?
>
>> The following patch uses the clocksource clock for a time value in
>> case get_cycles returns 0. As clocksource may not be available
>> during boot time, a flag is introduced which allows random.c to
>> check the availability of clocksource.
>
>I'm a bit concerned about doing things this way because reading the
>clocksource clock might be quite heavyweight, and we need something
>which is very low overhead, since we call get_cycles() on every single
>interrupt.  If reading fom the clocksource clock is the equivalent of
>a L3 cache miss (or worse) doing this on every single interrupt could
>be highly problematic.  So I think we will need to implement a
>random_get_fast_cycles() for each platform for which get_cycles() is
>not available.  In some cases we may be able to use the local clock
>source (if that's the best we can do), but in others, that may not be
>appropriate at all.

In any case, we need to make sure that get_cycles (or its planned 
replacement random_get_fast_cycles) must deliver a high-resolution 
timer.

However, as the RNG is critical to crypto, we should make sure that we 
have a fix rather sooner than later.

Why do you say that clocksource is heavyweight? Yes, there is a bit more 
code than for get_cycles, but that is all just leading to usually an 
equally small clock read code as get_cycles.

Moreover, until having your proposed real fix, wouldn't it make sense to 
have an interim patch to ensure we have entropy on the mentioned 
platforms? I think /dev/random is critical enough to warrant some cache 
miss even per interrupt?
>
>Cheers,
>
>					- Ted


Ciao
Stephan
-- 
| Nimm das Recht weg -                                             |
|  was ist dann der Staat noch anderes als eine große Räuberbande? |

--
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/

Powered by blists - more mailing lists