linux-kernel - random: locking vs. lockless accesses

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

Date:	Mon, 11 Nov 2013 14:52:17 -0500
From:	Greg Price <price@....EDU>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-kernel@...r.kernel.org, Jiri Kosina <jkosina@...e.cz>
Subject: random: locking vs. lockless accesses

Hi Ted,

After reading through the RNG code, I'm curious about one aspect and I
wonder if you can shed light on it.  Since v3.6-rc1~26^2~30 ("random:
use lockless techniques in the interrupt path"), we mix bytes into the
pool without taking the lock, when inside add_interrupt_randomness().
This means we may mix concurrently with mixing from other input
sources or with hashing the pool in extract_buf().  Nevertheless we
still take the lock in those other situations.

What do you think are the consequences of accessing the pool
concurrently?  If it's OK to do, should we be doing so everywhere?

By my reading, the only mutable data on a pool that we consistently
protect with the lock is ->last_data and ->last_data_init.  If
everything else were accessed without the lock, the only lock-taking
that would survive is what we do in extract_entropy when fips_enabled
is true.

Thanks, cheers,
Greg
--
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/