Thread (2 messages) 2 messages, 2 authors, 2022-12-05

Re: [PATCH v11 3/4] random: introduce generic vDSO getrandom() implementation

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2022-12-05 19:04:29
Also in: linux-crypto, linux-patches, lkml

Hi Florian,

On Mon, Dec 05, 2022 at 07:56:47PM +0100, Florian Weimer wrote:
* Jason A. Donenfeld:
quoted
+retry_generation:
+	/*
+	 * @rng_info->generation must always be read here, as it serializes @state->key with the
+	 * kernel's RNG reseeding schedule.
+	 */
+	current_generation = READ_ONCE(rng_info->generation);
quoted
+		if (unlikely(READ_ONCE(state->generation) != READ_ONCE(rng_info-
I'm pretty sure you need some sort of barrier here.  We have a similar
TM-lite construct in glibc ld.so for locating link maps by address, and
there the compiler performed reordering.

  _dl_find_object miscompilation on powerpc64le
  <https://sourceware.org/bugzilla/show_bug.cgi?id=28745>

I'm not familiar with READ_ONCE, but Documentation/atomic_t.txt suggests
it's a “regular LOAD”, and include/asm-generic/rwonce.h concurs.
Do you mean compiler barriers or SMP barriers?
Likewise, the signal safety mechanism needs compiler barriers (signal
fences).
READ_ONCE() should prevent the compiler from reordering the read.
 
I'm also not sure how READ_ONCE realizes atomic 64-bit reads on 32-bit
platforms.  i386 can do them in user space via the FPU worst-case (if
the control word hasn't been corrupted).  CMPXCHG8B is not applicable
here because it's a read-only mapping.  Maybe add a comment at least
about that “strong prevailing wind”?
There's read tearing in that case, which isn't super, but perhaps not
all together harmful.

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help