linux-kernel - Re: [PATCH-v2 4/4] random: clean up interrupt entropy accounting for archs w/o cycle counters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140614160041.GI6447@thunk.org>
Date:	Sat, 14 Jun 2014 12:00:41 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH-v2 4/4] random: clean up interrupt entropy accounting for
 archs w/o cycle counters

On Sat, Jun 14, 2014 at 03:28:49AM -0400, George Spelvin wrote:
> +	if (cycles || (fast_pool->notimer_count >= 32))
> +		credit++;
> 
> Ah, this addresses my concern about too few interrupts, too.  If the
> (non-timer) interrupt rate is less than 32/second, you'll never get any
> credit.

I'll want to measure the interrupt rate on things like a mobile
handset to see if this is a real problem or not, but the real question
is if you don't have a cycle counter, and the system is largely idle,
*and* all of the clocks are driven off of the same master oscillator,
how much entropy do you really get from measuring timing interrupts
where your time measurement has a granularity of 1/HZ seconds?  

Basically, at that point, you're getting most of your entorpy from
instruction_pointer(regs), and whatever the value of irq is --- and if
irq is mostly TIMER_IRQ, there's not much entropy there either.

Also note that the question is not whether the non-timer interrupt
rate is less than 32 seconds, but rather out of the last 64
interrupts, how many of the interrupts come from non-timer sources?
That's not the same thing, especially if you are running in tickless
mode, which most modern kernels for mobile handsets would want to do
for the obvious power savings reason.  Indeed the main concern on most
mobile handsets is that there aren't that many interrupts to begin
with, because they've been optimized out as much as possible.

The real answer is that ARM manufacuters have to get off their !@#!@?
duff and give us either a real clock cycle counter, or a real hardware
randum number generator, or both...

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