linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* arc4random - are you sure we want these?
@ 2022-07-23 16:22 Jason A. Donenfeld
  2022-07-23 16:25 ` Jason A. Donenfeld
  0 siblings, 1 reply; 74+ messages in thread
From: Jason A. Donenfeld @ 2022-07-23 16:22 UTC (permalink / raw)
  To: gibc-alpha, Adhemerval Zanella Netto, Florian Weimer,
	Yann Droneaud, jann, Michael
  Cc: linux-crypto

Hi glibc developers,

I learned about the addition of the arc4random functions in glibc this
morning, thanks to Phoronix. I wish somebody would have CC'd me into
those discussions before it got committed, but here we are.

I really wonder whether this is a good idea, whether this is something
that glibc wants, and whether it's a design worth committing to in the
long term.

Firstly, for what use cases does this actually help? As of recent
changes to the Linux kernels -- now backported all the way to 4.9! --
getrandom() and /dev/urandom are extremely fast and operate over per-cpu
states locklessly. Sure you avoid a syscall by doing that in userspace,
but does it really matter? Who exactly benefits from this?

Seen that way, it seems like a lot of complexity for nothing, and
complexity that will lead to bugs and various oversights eventually.

For example, the kernel reseeds itself when virtual machines fork using
an identifier passed to the kernel via ACPI. It also reseeds itself on
system resume, both from ordinary S3 sleep but also, more importantly,
from hibernation. And in general, being the arbiter of entropy, the
kernel is much better poised to determine when it makes sense to reseed.

Glibc, on the other hand, can employ some heuristics and make some
decisions -- on fork, after 16 MiB, and the like -- but in general these
are lacking, compared to the much wider array of information the kernel
has.

You miss out on this with arc4random, and if that information _is_ to be
exported to userspace somehow in the future, it would be awfully nice to
design the userspace interface alongside the kernel one.

For that reason, past discussion of having some random number generation
in userspace libcs has geared toward doing this in the vDSO, somehow,
where the kernel can be part and parcel of that effort.

Seen from this perspective, going with OpenBSD's older paradigm might be
rather limiting. Why not work together, between the kernel and libc, to
see if we can come up with something better, before settling on an
interface with semantics that are hard to walk back later?

As-is, it's hard to recommend that anybody really use these functions.
Just keep using getrandom(2), which has mostly favorable semantics.

Yes, I get it: it's fun to make a random number generator, and so lots
of projects figure out some way to make yet another one somewhere
somehow. But the tendency to do so feels like a weird computer tinkerer
disease rather something that has ever helped the overall ecosystem.

So I'm wondering: who actually needs this, and why? What's the
performance requirement like, and why is getrandom(2) insufficient? And
is this really the best approach to take? If this is something needed,
how would you feel about working together on a vDSO approach instead? Or
maybe nobody actually needs this in the first place?

And secondly, is there anyway that glibc can *not* do this, or has that
ship fully sailed, and I really missed out by not being part of that
discussion whenever it was happening?

Thanks,
Jason

^ permalink raw reply	[flat|nested] 74+ messages in thread

end of thread, other threads:[~2022-07-28 11:01 UTC | newest]

Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-23 16:22 arc4random - are you sure we want these? Jason A. Donenfeld
2022-07-23 16:25 ` Jason A. Donenfeld
2022-07-23 17:18   ` Paul Eggert
2022-07-24 23:55     ` Jason A. Donenfeld
2022-07-25 20:31       ` Paul Eggert
2022-07-23 17:39   ` Adhemerval Zanella Netto
2022-07-23 22:54     ` Jason A. Donenfeld
2022-07-25 15:33     ` Rich Felker
2022-07-25 15:59       ` Adhemerval Zanella Netto
2022-07-25 16:18       ` Sandy Harris
2022-07-25 16:40       ` Florian Weimer
2022-07-25 16:51         ` Jason A. Donenfeld
2022-07-25 17:44         ` Rich Felker
2022-07-25 18:33           ` Cristian Rodríguez
2022-07-25 18:49             ` Rich Felker
2022-07-25 18:49               ` Rich Felker
     [not found]               ` <YuCa1lDqoxdnZut/@mit.edu>
     [not found]                 ` <a5b6307d-6811-61b6-c13d-febaa6ad1e48@linaro.org>
     [not found]                   ` <YuEwR0bJhOvRtmFe@mit.edu>
2022-07-27 12:49                     ` Florian Weimer
2022-07-27 20:15                       ` Theodore Ts'o
2022-07-27 21:59                         ` Rich Felker
2022-07-28  0:30                           ` Theodore Ts'o
2022-07-28  0:39                         ` Cristian Rodríguez
2022-07-23 19:04   ` Cristian Rodríguez
2022-07-23 22:59     ` Jason A. Donenfeld
2022-07-24 16:23       ` Cristian Rodríguez
2022-07-24 21:57         ` Jason A. Donenfeld
2022-07-25 10:14     ` Florian Weimer
2022-07-25 10:11   ` Florian Weimer
2022-07-25 11:04     ` Jason A. Donenfeld
2022-07-25 12:39       ` Florian Weimer
2022-07-25 13:43         ` Jason A. Donenfeld
2022-07-25 13:58           ` Cristian Rodríguez
2022-07-25 16:06           ` Rich Felker
2022-07-25 16:43             ` Florian Weimer
2022-07-26 14:27         ` Overwrittting AT_RANDOM after use (was Re: arc4random - are you sure we want these?) Yann Droneaud
2022-07-26 14:35         ` arc4random - are you sure we want these? Yann Droneaud
2022-07-25 13:25       ` Jeffrey Walton
2022-07-25 13:48         ` Jason A. Donenfeld
2022-07-25 14:56     ` Rich Felker
2022-07-25 22:57   ` [PATCH] arc4random: simplify design for better safety Jason A. Donenfeld
2022-07-25 23:11     ` Jason A. Donenfeld
2022-07-25 23:28     ` [PATCH v2] " Jason A. Donenfeld
2022-07-25 23:59       ` Eric Biggers
2022-07-26 10:26         ` Jason A. Donenfeld
2022-07-26  1:10       ` Mark Harris
2022-07-26 10:41         ` Jason A. Donenfeld
2022-07-26 11:06           ` Florian Weimer
2022-07-26 16:51           ` Mark Harris
2022-07-26 18:42             ` Jason A. Donenfeld
2022-07-26 19:24               ` Jason A. Donenfeld
2022-07-26  9:55       ` Florian Weimer
2022-07-26 11:04         ` Jason A. Donenfeld
2022-07-26 11:07           ` [PATCH v3] " Jason A. Donenfeld
2022-07-26 11:11             ` Jason A. Donenfeld
2022-07-26 11:12           ` [PATCH v2] " Florian Weimer
2022-07-26 11:20             ` Jason A. Donenfeld
2022-07-26 11:35               ` Adhemerval Zanella Netto
2022-07-26 11:33       ` Adhemerval Zanella Netto
2022-07-26 11:54         ` Jason A. Donenfeld
2022-07-26 12:08           ` Jason A. Donenfeld
2022-07-26 12:20           ` Jason A. Donenfeld
2022-07-26 12:34           ` Adhemerval Zanella Netto
2022-07-26 12:47             ` Jason A. Donenfeld
2022-07-26 13:11               ` Adhemerval Zanella Netto
2022-07-26 13:30     ` [PATCH v4] " Jason A. Donenfeld
2022-07-26 15:21       ` Yann Droneaud
2022-07-26 16:20       ` Adhemerval Zanella Netto
2022-07-26 18:36         ` Jason A. Donenfeld
2022-07-26 19:08       ` [PATCH v5] " Jason A. Donenfeld
2022-07-26 19:58         ` [PATCH v6] " Jason A. Donenfeld
2022-07-26 20:17           ` Adhemerval Zanella Netto
2022-07-26 20:56             ` Adhemerval Zanella Netto
2022-07-28 10:29           ` Szabolcs Nagy
2022-07-28 10:36             ` Szabolcs Nagy
2022-07-28 11:01               ` Adhemerval Zanella

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).