linux-kernel - Re: [PATCH 02/10] random: use lockless techniques when mixing entropy pools

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]

Date:	Thu, 5 Jul 2012 11:18:47 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	w@....eu, ewust@...ch.edu, zakir@...ch.edu, greg@...ah.com,
	mpm@...enic.com, nadiah@...ucsd.edu, jhalderm@...ch.edu,
	tglx@...utronix.de, davem@...emloft.net
Subject: Re: [PATCH 02/10] random: use lockless techniques when mixing entropy pools

On Thu, Jul 5, 2012 at 11:12 AM, Theodore Ts'o <tytso@....edu> wrote:
>
> Also, we will use a trylock when trying to increase then entropy
> accounting during the interrupt path to avoid taking a spinlock there;
> if there is contention, we will simply not credit the entropy count,
> thus failing safe.  Thanks to Dan Carpenter for suggesting this
> approach.

Actually, I hate that. If the *only* thing the spinlock protects is
that entropy count, then use one single cmpxchg() for that field
instead.

The trylock means that now you need to disable interrupts etc. Just
don't do it. Do things entirely locklessly, and minimizing atomics.
Quite frankly, I think that protecting the entropy count is completely
idiotic, since it's not "real" in any form anyway, but if you
absolutely have to, a single cmpxchg is much better than playing games
with spinlocks and interrupt disables.

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