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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	14 Jun 2014 12:23:19 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, tytso@....edu
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH-v2 4/4] random: clean up interrupt entropy accounting for archs w/o cycle counters

I agree with your points, with one exception.  Which may be
me misunderstanding.

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

When you say "the question is", do you mean that's what you eant
the code to do?  Because that's not what it does right now.

The condition for not spilling is

	if ((fast_pool->count & 63) && !time_after(now, fast_pool->last + HZ))
		return;

In other words, spill if there have been 64 samples *or* 1 second since
the last spill.

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

I've thought of beating the RTC against the main oscillator.
But which I know a lot of SoCs have an battery-backed RTC, I don't
know how universal an RTC is.

The other nice source is an otherwise unused ADC.  Even if the input
is shorted out, there's lsbit noise.  but again, not everything has
an audio ADC.
--
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/