Linux Proposal Adding getrandom() To The vDSO For Better Performance

[phoronix]

Phoronix: Linux Proposal Adding getrandom() To The vDSO For Better Performance

Jason Donenfeld of WireGuard fame who has recently been spending much work on improving Linux's "random" kernel code has sent out a proposal adding getrandom() support to the vDSO for better performance in seeking to better address the needs of user-space developers...

https://www.phoronix.com/news/Linux-getrandom-vDSO

[billyswong]

I think there are valid scenarios where one want to use pseudo random numbers instead of true random numbers, especially for repeatable AI workload or physics simulation. The only thing debatable is if we should provide such generator in standard library.

[Gonk]

I see no need for debate on that; a repeatable pseudorandom number generator belongs in a specialized library, not libc. In libc it would just be a footgun.

What I would like to see in glibc is more hashing functions (eg. what libxcrypt provides). The use of better hashing should be widely encouraged and as frictionless as possible.

[archkde]

Interesting. I wonder whether the per-process page thing could be used to put other stuff like get{,e,res}{u,g}id, getpid, getppid or getpgrp into the vDSO.

[Vorpal]

Interesting. I wonder whether the per-process page thing could be used to put other stuff like get{,e,res}{u,g}id, getpid, getppid or getpgrp into the vDSO.

In theory yes (though at some point you need to allocate multiple pages for the data). In practice is there really a need for it? I don't believe that these functions are performance critical. They are simply not called that often.

[billyswong]

A pseudorandom number generator is already there as rand() plus srand() in stdlib. If it is a foot gun, we are probably stuck without any choice of stop providing it. We can only seek to make it shoot one's foot less often.

[cl333r]

I see no need for debate on that; a repeatable pseudorandom number generator belongs in a specialized library, not libc. In libc it would just be a footgun.

What I would like to see in glibc is more hashing functions (eg. what libxcrypt provides). The use of better hashing should be widely encouraged and as frictionless as possible.

I'm totally a side person, but why not have a function that yields different results (and speed) based on an incoming parameter, say in glibc like this pseudo code:
getrandom(RANDOM_TRUE); // slower but true randomness
getrandom(RANDOM_PSEUDO); // quicker execution

and glibc internally should call the proper (kernel?) function.

[sinepgib]

I'm totally a side person, but why not have a function that yields different results (and speed) based on an incoming parameter, say in glibc like this pseudo code:
getrandom(RANDOM_TRUE); // slower but true randomness
getrandom(RANDOM_PSEUDO); // quicker execution

and glibc internally should call the proper (kernel?) function.

For a start because we have already different functions, but I could also point out that by doing that you need to overflow just one byte of the stack to make it return non-random numbers when real randomness was needed.

I think there are valid scenarios where one want to use pseudo random numbers instead of true random numbers, especially for repeatable AI workload or physics simulation. The only thing debatable is if we should provide such generator in standard library.

Those are part of the standard library. The function in discussion was always about real randomness.

[uxmkt]

I think there are valid scenarios where one want to use pseudo random numbers instead of true random numbers

getrandom() also gives you pseudo-random numbers—which is why adding arc4random now seems so arbitrary.
Manpage for getrandom: ""By default, getrandom() draws entropy from the urandom source""
Manpage for urandom: ""When read, the /dev/urandom device returns random bytes using a pseudo-random number generator seeded from the entropy pool.""

[ryao]

I think there are valid scenarios where one want to use pseudo random numbers instead of true random numbers, especially for repeatable AI workload or physics simulation. The only thing debatable is if we should provide such generator in standard library.

We use them in OpenZFS:

https://github.com/openzfs/zfs/blob/master/module/os/linux/spl/spl-generic.c#L62

https://github.com/openzfs/zfs/blob/master/module/zfs/vdev_draid_rand.c

That said, I am surprised that this is such a problem for people. There are very tiny high quality pseudo random number generators from the xorshift family. We adopted them in OpenZFS for use in the kernel where we need a large quantity of random numbers. CPU time dropped by 3% from adopting them.