linux-kernel - Re: [PATCH] random: mix all saved registers into entropy pool

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]

Date:	Wed, 11 Jun 2014 11:27:42 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jörn Engel <joern@...fs.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: mix all saved registers into entropy pool

On Tue, Jun 10, 2014 at 08:10:09PM -0400, Jörn Engel wrote:
> > I'm also concerned about how much overhead this might eat up.  I've
> > already had someone who was benchmarking a high performance storage
> > array where the increased interrupt latency before adding something
> > like this was something he noticed, and kvetched to me about.  The
> > pt_regs structure is going to be larger than the fast_pool (which is
> > only 16 bytes), and we're going to be doing it once every jiffy, which
> > means between 100 and 1000 times per second.
> 
> Would that someone be me? ;)
> 
> The reason I prefer doing it once every jiffy is that it doesn't
> change with interrupt load.  You get 10k interrupts per second?
> You pay once per jiffy.  100k interrupts per second?  Pay once per
> jiffy.

No, actually, it was someone who was worried about tail latency.  So
even if the average overhead was small, if once a jiffy we had a much
larger time spent in the interrupt handler, that's something that
would a big concern for someone who was worried about big storage
array performance.

I'd be happier if we used fast_mix() and mixed the registers into the
fast pool.  That's much lighter weight than using mix_pool_bytes(),
which involves many more memory accesses, MUCH higher probably of
cache line bouncing between CPU's, etc.

And there has been some proposals that I've been looking at to make
fast_mix to be use even less overhead, so if we use fast_mix, any
changes we make to improve that will help here too.

> What I like about my approach is quite the opposite.  The only thing
> an architecture maintainer can mess up is not saving registers on
> interrupts.  And if they mess that one up, they are very likely to
> notice.

What probably makes sense is to make the defaults use pt_regs, but
make it be overrideable by the architecture maintainer.  For example,
if the CPU has RDRAND or RDSEED, it probably doesn't make sense to
worry about mixing in the registers.  So we could make the default be
to mix in the entire set of registers, and if someone complains about
the overhead on their system, and they have a better way of harvesting
high quality entropy, then they can use that instead of trying to rely
on the registers.

It's unlikely that someone is going to be attaching a multi-million
dollar RAID array or a PCIe attached flash device on a MIPS or m68k
platform, after all.  :-)

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