Linux getrandom() vDSO Patch Updated For ~15x Speedup

[phoronix]

Phoronix: Linux getrandom() vDSO Patch Updated For ~15x Speedup

Over the summer Jason Donenfeld of WireGuard fame proposed adding getrandom() to the vDSO for better performance to enjoy by user-space developers. This past week he sent out the latest version of this proposed kernel patch where he's seeing around a ~15x speed-up with this change...

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

[schmidtbag]

I find it both weird and a little irritating how obsessive we are over random numbers. It seems like every 2 months, there's yet another change with how they work. Anyone who actually cares enough should not be using software-based random numbers.

[david-nk]

I find it both weird and a little irritating how obsessive we are over random numbers. It seems like every 2 months, there's yet another change with how they work. Anyone who actually cares enough should not be using software-based random numbers.

getrandom() isn't purely software-based, that is the entire point. The goal is to deliver cryptographically secure random numbers while still achieving high performance.
A goal that has already been met by the Linux kernel at this point in time.

[MauganRa]

Random numbers are at the core of many cryptographic protocols. For these, even slight biases in the stream can break security. This also affects TLS, which is a use case where it is simply unrealistic to expect users to invest in hardware security modules. For these cases, random number generation also has to be *fast*. Of course, there are use cases where people should really invest in HSMs instead, for example certificate signing applications.

[JEBjames]

Michael

Typo/Grammar

"designed two address two problems" should be "designed to address two problems"

"to incorporate feedback to avoid behavior changes and making vgetrandom_alloc a system call" should probably be "to incorporate feedback to avoid behavior changes and make vgetrandom_alloc a system call"

[schmidtbag]

A goal that has already been met by the Linux kernel at this point in time.

Exactly my point - why is this even a topic of discussion when it has already been done?

Random numbers are at the core of many cryptographic protocols. For these, even slight biases in the stream can break security. This also affects TLS, which is a use case where it is simply unrealistic to expect users to invest in hardware security modules. For these cases, random number generation also has to be *fast*. Of course, there are use cases where people should really invest in HSMs instead, for example certificate signing applications.

Also catering to my point: if you need something truly secure, this shouldn't even be a topic of discussion. If you want something fast and secure, I'm sure there are many ways to go about doing that.

[quaz0r]

moar betterer 👍🏻

[rmfx]

I find it both weird and a little irritating how obsessive we are over random numbers. It seems like every 2 months, there's yet another change with how they work. Anyone who actually cares enough should not be using software-based random numbers.

Ok NSA employee..

[pal666]

Exactly my point - why is this even a topic of discussion when it has already been done?

why don't you read accompanying pdf slides?

[zx2c4]

I find it both weird and a little irritating how obsessive we are over random numbers. It seems like every 2 months, there's yet another change with how they work.

"we" - I can't speak for the crowd, in which many seem indeed a bit over obsessive, but I can tell you that when I started developing random.c at the beginning of the year, it had a lot of major issues accumulated over many years. I've now succeeded in handling many of those issues, but more still remain. So I'll probably continue to chip away at them until it's finished. This isn't development for development sake -- I do in fact have other things I could be doing -- but development because it's not done yet.

If you have any particular questions on why a very particular change was made, maybe I can answer that.