linux-kernel - Re: [PATCH 01/10] random: make 'add_interrupt

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1207252015020.32033@ionos>
Date:	Wed, 25 Jul 2012 20:43:22 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Theodore Ts'o <tytso@....edu>, Matt Mackall <mpm@...enic.com>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	w@....eu, ewust@...ch.edu, zakir@...ch.edu, greg@...ah.com,
	nadiah@...ucsd.edu, jhalderm@...ch.edu, davem@...emloft.net,
	stable@...nel.org
Subject: Re: [PATCH 01/10] random: make 'add_interrupt_randomness()' do
 something sane

On Fri, 6 Jul 2012, Linus Torvalds wrote:

> On Fri, Jul 6, 2012 at 6:01 AM, Theodore Ts'o <tytso@....edu> wrote:
> > What in the world is "fast count"?  I've grepped for it,
> > and I can't find it.
> 
> It's your own fast-pool counter that Matt was talking about.
> 
> > I can simply not credit entropy of the timer is on the irq, but I
> > think you and Matt were suggesting more subtle.  I just have no idea
> > how to tell if there were non-timer interrupts during the last HZ
> > cycle.  Can you give me a hint?
> 
> So instead of not calling the add_interrupt_randomness() at all if the
> __IRQF_TIMER bit was set, just pass it in as an argument. That way you
> can still use the cycle counter for mixing stuff, but the random.c
> code could at least (perhaps in the future) decide that if all it has
> seen is timer interrupts, and get_cycles() always returns zero (no
> cycle counter), we won't count it as entropy.
> 
> At least with no-HZ there's still going to be *some* data there
> because you won't get called for every tick, so things like random app
> timers etc will affect even the timer interrupt distribution, but...

There is only one constellation which will not be able to deliver
randomness via the timer interrupt and a "cycle counter":

Systems, which do not have an usable fine granular clocksource and
therefor are completely based on jiffies. Those systems have neither
high resolution timers nor NOHZ idle for obvious reasons.

Though almost all systems which we care about have a more or less
useful clocksource and register it proper with the core.

So we could do the following in the core code when a clocksource is
registered:

Aside of considering it to handle the timekeeping stuff, which has
different criteria, we could filter out the clocksource with the
highest frequency and provide a function which allows us to access it
for randomness and other purposes. IOW, a generic "get_cycles"
implementation.

Now, if the only available clocksource is jiffies, which is completely
useless, as it gets incremented once per timer interrupt (and there is
no distribution possible due to the lack of NOHZ support) then the
function returns 0 which allows the random code to discard it as a
entropy source.

We might consider to put a low frequency limit into that selection
process as well, but that needs some thought and experimentation.

Thanks,

	tglx

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