On Thu, Oct 10, 2013 at 08:50:17AM +0200, Pavel Machek wrote:
> On the system with good power management and idle cpus (many of them), I'd
> expect most of the IPs to be pretty much equal -- arch specific version of
> "enter low power state" (mwait on recent intel machines, for example).
>
> Would
Hi!
(Sorry to be late and maybe with very early date).
On Tue 2013-09-10 14:25:24, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 06:54:38PM +0200, Stephan Mueller wrote:
>
> > Moreover, until having your proposed real fix, wouldn't it make sense to
> > have an interim patch to ensure we have e
Am Freitag, 13. September 2013, 14:59:31 schrieb Theodore Ts'o:
Hi Theodore,
>On Fri, Sep 13, 2013 at 07:36:20AM +0200, Stephan Mueller wrote:
>
>However, if you are worried about a malicious entropy source, things
>are a little bit different. Suppose RDRAND == AES(i++, NSA_KEY),
>where the NSA
On Fri, Sep 13, 2013 at 07:36:20AM +0200, Stephan Mueller wrote:
>
> And here the RNG theory breaks: a whitening function (crypto function)
> like the used SHA1 does not add entropy. Thus, the SHA1 just spreads out
> the entropy evenly over the output buffer. As entropy can be considered
> as a
On Fri, Sep 13, 2013 at 11:54:40AM +, Thorsten Glaser wrote:
>
> That’s why you also use a (faster, less powerful) mixing function
> on input.
>
> I was wondering: why not use Jenkins’ one-at-a-time hash there?
> I’ve worked with it a bit, and it has good avalanche behaviour;
> I didn’t measu
On Fri, 13 September 2013 07:36:20 +0200, Stephan Mueller wrote:
> Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
> >
> >The basic principle of Ted's RNG is very simple and quite sane:
> >- You collect as much data as possible, some of which is (hopefully)
> > unpredictable.
> >-
Stephan Mueller chronox.de> writes:
> And here the RNG theory breaks: a whitening function (crypto function)
> like the used SHA1 does not add entropy. Thus, the SHA1 just spreads out
> the entropy evenly over the output buffer. As entropy can be considered
That’s why you also use a (faster,
Stephan Mueller chronox.de> writes:
> A monotonic counter is fully ok. Note, for /dev/random, the occurrence
> of events delivers entropy. Thus, we have to be able to precisely
> measure that occurrence. The timer itself does not need to deliver any
> entropy as long as it is fast.
Rather the
Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
Hi Jörn,
>On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
>> Though
>> I probably should be hesitant with my suggestions, as I'm not well
>> versed in RNG theory.
>
>The basic principle of Ted's RNG is very simple and qu
On Thu, 12 September 2013 19:35:36 -0400, Jörn Engel wrote:
>
> I think the existing code is doing just fine for low interrupt loads.
> It makes sense to spend a bit more work to squeeze the last bit of
> randomness out. But when you get lots of interrupts, you can be
> sloppy and just xor things
On Thu, 12 September 2013 19:31:55 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
> >
> > I happen to have a real-world system with >100k interrupts per second
> > and - surprise - add_interrupt_randomness() showed up prominently in
> > the profiles. I w
On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
>
> I happen to have a real-world system with >100k interrupts per second
> and - surprise - add_interrupt_randomness() showed up prominently in
> the profiles. I was also told twice to just remove that call. I
> resisted both times and
On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
> Though
> I probably should be hesitant with my suggestions, as I'm not well
> versed in RNG theory.
The basic principle of Ted's RNG is very simple and quite sane:
- You collect as much data as possible, some of which is (hopefully)
On Thu, 12 September 2013 14:15:35 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller wrote:
> >>BTW, I prefer a different name than "random_get_fast_cycles()", as it's
> >>better to have something that returns different and unpredictable
> >>numbers than an actual
On Tue, 10 September 2013 20:50:47 -0400, Theodore Ts'o wrote:
>
> Yep. The worse case would probably a serial port running at 230400
> bps. Even with a 16550A UART with the 16-byte FIFO, we're talking
> about close to 2,000 interrupts per second. A 16450 running at 115200
> bps would give us 1
On 09/10/2013 05:50 PM, Theodore Ts'o wrote:
>
> Right now, if get_cycles() returns 0, we fall back to only mixing in
> the IP register from the interrupt plus the jiffies counter. The
> platforms where get_cycles returns 0 is:
>
> - User mode Linux
UML (on x86) should be able to use RDTSC just
On Thu, Sep 12, 2013 at 01:59:04PM +0200, Geert Uytterhoeven wrote:
>
> BTW, I prefer a different name than "random_get_fast_cycles()", as it's better
> to have something that returns different and unpredictable numbers than an
> actual monotonic cycle counter.
I'm open to a different name; the p
Am Donnerstag, 12. September 2013, 14:47:23 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:35 PM, Stephan Mueller
wrote:
>>>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
>>>
>>>
>> wrote:
>BTW, I prefer a different name than "random_get_fast_cycles()", as
>it's bett
On Thu, Sep 12, 2013 at 2:35 PM, Stephan Mueller wrote:
>>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
> wrote:
BTW, I prefer a different name than "random_get_fast_cycles()", as
it's better to have something that returns different and
unpredictable numbers than an actual monotoni
Am Donnerstag, 12. September 2013, 14:15:35 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
wrote:
>>>BTW, I prefer a different name than "random_get_fast_cycles()", as
>>>it's better to have something that returns different and
>>>unpredictable numbers t
On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller wrote:
>>BTW, I prefer a different name than "random_get_fast_cycles()", as it's
>>better to have something that returns different and unpredictable
>>numbers than an actual monotonic cycle counter.
>
> A monotonic counter is fully ok. Note, for /de
Am Donnerstag, 12. September 2013, 13:59:04 schrieb Geert Uytterhoeven:
Hi Geert,
>On Wed, Sep 11, 2013 at 8:49 AM, Stephan Mueller
wrote:
>> __u64 tmp = random_get_fast_cycles() - random_get_fast_cycles();
>> if(0 == tmp)
>>
>> return fail;
>>
>> return pass;
>
>That will fail if the
On Wed, Sep 11, 2013 at 8:49 AM, Stephan Mueller wrote:
> __u64 tmp = random_get_fast_cycles() - random_get_fast_cycles();
> if(0 == tmp)
> return fail;
> return pass;
That will fail if the cycle counter runs at less than say 4 times the
CPU clock...
BTW, I prefer a different name than "
Am Dienstag, 10. September 2013, 17:14:54 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Sep 10, 2013 at 10:48:00PM +0200, Geert Uytterhoeven wrote:
>> So the first importance for random_get_fast_cycles() is that it needs
>> to be fast. What's most important next: number of bits or
>> high-frequenc
On 09/10/2013 05:50 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 05:31:45PM -0700, John Stultz wrote:
>> Yea, that point about "every single interrupt" vs "every timer
>> interrupt". I suspect that if its every timer interrupt, this can be
>> done easily w/ clocksources as we already do that
On Tue, Sep 10, 2013 at 05:31:45PM -0700, John Stultz wrote:
> Yea, that point about "every single interrupt" vs "every timer
> interrupt". I suspect that if its every timer interrupt, this can be
> done easily w/ clocksources as we already do that read, but every single
> interrupt would have pote
On 09/10/2013 03:33 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 03:08:12PM -0700, John Stultz wrote:
>> One other area you might look at is using the delta between when the
>> next hrtimer was scheduled for and when we actually expired it? That's
>> something we could cheaply calculate on ev
On Tue, Sep 10, 2013 at 03:08:12PM -0700, John Stultz wrote:
> One other area you might look at is using the delta between when the
> next hrtimer was scheduled for and when we actually expired it? That's
> something we could cheaply calculate on every hrtimer expiration. Though
> I probably should
On 09/10/2013 02:10 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 01:46:21PM -0700, John Stultz wrote:
>> We do read the clocksource fairly frequently though, so rather then
>> re-reading on each interrupt, could you instead re-use the points at
>> interrupt time where we already read the cloc
On 09/10/2013 12:47 PM, Stephan Mueller wrote:
> Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Sep 10, 2013 at 4:31 AM, Stephan Mueller
> wrote:
>>> Hi,
>>>
>>> /dev/random uses the get_cycles() function to obtain entropy in
>>> addition to jiffies and t
On Tue, Sep 10, 2013 at 10:48:00PM +0200, Geert Uytterhoeven wrote:
>
> So the first importance for random_get_fast_cycles() is that it needs to
> be fast. What's most important next: number of bits or high-frequency?
High-frequency. For example MIPS has a register which is bumped at
every clock
On Tue, Sep 10, 2013 at 12:38:56PM -0700, John Stultz wrote:
> So the end of timekeeping_init() may not be what you want here. This
> only means we've started up the timekeping core with only the default
> clocksource (with only few exceptions, this is almost always jiffies).
> Then as clocksource
On Tue, Sep 10, 2013 at 5:04 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
>> /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 g
On 09/10/2013 01:38 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 12:38:56PM -0700, John Stultz wrote:
>> So the end of timekeeping_init() may not be what you want here. This
>> only means we've started up the timekeping core with only the default
>> clocksource (with only few exceptions, this
On Tue, Sep 10, 2013 at 01:46:21PM -0700, John Stultz wrote:
>
> We do read the clocksource fairly frequently though, so rather then
> re-reading on each interrupt, could you instead re-use the points at
> interrupt time where we already read the clocksource, like in
> hrtimer_interrupt()?
How of
Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:
Hi John,
>On Tue, Sep 10, 2013 at 4:31 AM, 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
On Tue, Sep 10, 2013 at 12:38 PM, John Stultz wrote:
> On Tue, Sep 10, 2013 at 4:31 AM, 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
On Tue, Sep 10, 2013 at 4:31 AM, 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 ev
Am Dienstag, 10. September 2013, 14:25:24 schrieb Theodore Ts'o:
Hi Theodore,
>
>Also note that the clocksource is not necessarily be the best choice;
>it may not be the most fine grained sampling that we have available
>(that is certainly be true for MIPS). So doing something hacky
>doesn't abs
On Tue, Sep 10, 2013 at 06:54:38PM +0200, Stephan Mueller wrote:
>
> 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.
I've had past experiences where a c
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.
>>
>> Typic
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, beca
On Tue, Sep 10, 2013 at 1:31 PM, Stephan Mueller wrote:
> /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 valu
43 matches
Mail list logo
