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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
