For what it's worth, this is the approach OpenBSD has taken; they made a decent random number generator and highly encourage people to use it over rolling their own. In addition, because so many OpenBSD subsystems leverage it, the entropy is rather high.
Thinking that the entropy is high because many processes share a psuedo-random function sounds less like an endorsement of its security and more like a prediction of a related side channel attack several years from now.
but on the other hand, can you guarantee that there wont be issues from devs implementing their own? I can't remember where I read it, but there was an example recently of someone pulling from a random spot in memory for entropy, which sat there for years, and then other devs came later on and asked "why are they pulling bytes from this random spot?" the consensus was that it was a mistake and they changed it... and it broke a lot of stuff.
Although the Linux kernel has to be a LOT more picky about what they add otherwise things could quickly become a giant mess, and once it is added, there is no good chance of removing it whether it sucks or not.
I don't know if this is the case you were thinking of, as it's not terribly recent, but this was the cause of [Debian Security Advisory 1571-1][d] in 2008. An OpenSSL developer used an uninitialized variable as a source of randomness (a pretty bad idea, as the contents often aren't very random) and failed to document what they were doing (a further bad idea), and a Debian maintainer decided to "fix" the code (yet another bad idea) so that static analysers would stop complaining about it. It meant the current process ID was the only source of randomness, and that keys generated on Debian (and related) systems for the past two years had to be considered compromised. More info [here][comm]. All round, it was pretty inept behaviour from both the OpenSSL developer (why on earth did they use such a stupid source of randomness, and fail to document it?) and the Debian maintainer (why on earth were they fiddling with a cryptographic library they didn't understand?).
[d]: https://lists.debian.org/debian-security-announce/2008/msg00152.html
[comm]: https://www.schneier.com/blog/archives/2008/05/random_number_b.html
[getrandom(2)](https://man7.org/linux/man-pages/man2/getrandom.2.html) is this already.
This patch wants to add the in-kernel variant of getrandom() into the vDSO - a way for userspace applications to more-or-less directly call kernel functions as a means to speed the applications up (by skipping the otherwise necessary and expensive user-to-kernel-to-user context switch).
Linus is upset that there are no real world users that *need* that kind of speed for random number generation that can't use their own userspace RNG with entropy streamed from getrandom(2). This code adds a tremendous amount of complexity and maintenance burden.
> Same, but why not provide an easy way to get random bytes for the average dev that would otherwise use epoch or some other similarly dumb thing?
I think you misunderstand the context. This is not about the question "Should the Linux kernel have an API for random numbers?" The Linux kernel has that already.
This is specifically about the vDSO, which is an implementation detail on how the Linux kernel API is being used. Not if the feature is there at all.
It isn't.
The argument put forth in favor of the patch is that the kernel is in a better position to seed its prng when required — such as after a VM is forked. In this situation, a userspace prng that periodically seeded with getrandom() could potentially duplicate random numbers until the next seed is drawn, but atm using getrandom() directly incurs syscall overhead which may have an unacceptable performance penalty.
> may have an unacceptable performance penalty.
Linus's main qualm is that "may have" is too abstract. There's no documented cases of the performance penalty being actually unacceptable in practice.
Although it's worth noting that later on in the thread, someone highlights a bug report in Chrony where this is causing an unacceptable performance penalty.
Hopefully someone can answer better than I can:
Basically the kernel has access to a hardware RNG(on most cpus, but not all) with greater entropy and randomness than is usually achieved in a straight software solution.
They want to make it part of vdso so that you can bypass the normal syscall overhead.
I actually think it’s a good idea.
Edit: I just reread the article and Linus is concerned with adding this because he thinks it’s too hard to make different consumers happy and it provides too little value. He also doesn’t want to maintain it. I guess I can get on board with that from an architecture standpoint.
It's actually wrong.
All software has access to hardware RNG (on modern x86 CPUs) via rdrand instruction, but it only produces up to 8 bytes of randomness per execution and is relatively slow. It is used to "seed" a PRNG based on chacha stream cipher which will produce unpredictable sequences much faster. This is what kernel level RNG does. The two benefits it has are running mostly uninterrupted (that gives a bit more performance) and built-in automatic periodic mixing of entropy sources like rdrand, system timer variance, net traffic statistics, etc.
In user space you will have to find and mix extra entropy sources yourself, but it's doable. You are just more likely to mess up the implementation.
If we are talking about real hardware RNGs, not just TPM or CPU, they are available via hw_random interface from user space.
The kernel utilities for getting random number is usually only used for seeding a PRNG that is then used fully in user-land to get more random data.
So if the user-land code is written by someone that knows what they are doing, it should perform only 1 call to kernel random utilities in its entire lifetime. So the entire performance argument make no sense in my view.
The issue is that if you're, for example, cloning a VM, one call per application lifetime isn't enough. The application doesn't know it's been cloned, but the kernel does, so application code risks, for example, generating duplicate identifiers.
The patch author doesn't mention it, although there are some comments by Linus that suggest he's aware of it as an argument but doesn't find it that convincing. There are some subsequent replies by others that do explicitly mention this use case.
> it should perform only 1 call to kernel random utilities in its entire lifetime. So the entire performance argument make no sense in my view.
I hope that you mean once per software application rather than user? Using same seed everywhere is dangerous.
I think [this article](https://lwn.net/Articles/919008/) explains the problem much better.
There's also [another article](https://lwn.net/SubscriberLink/980447/8719e2f48e7b8d70/) that's actually about this more recent patch set
To add a bit of context, this was in response to Linus asking a normal-ish question, Jason responding, and Linus calling BS. But then Jason Uno-recersed Linus and got this concession.
> > Jason. This smells. It's BS.
> It's not BS. And that's not a real argument from you, but rather is
something else.
He didn't just call it BS. Full quote:
> Jason. This smells. It's BS.
> Christ, let's make a deal: do a five-liner patch that adds the generation number to the vdso data, and basically document it as a "the kernel thinks you need to reseed your buffers using getrandom" flag.
> And *if* it turns out in the future that there is then any major reason why that doesn't work, I'll take the 1000+ line thing, ok?
> Deal?
I too would be pretty adamant about a 1000-line patch for something that could've been done in 5 lines. The code for rng is already there in the kernel, so I'm guessing that just re-using it in the vDSO shouldn't require 1000 more lines of code. And seeing how the author of said code has had multiple failed attempts to do this in the past 2 years, I'd be hesitant to review yet another 1000-line commit from him. Linus must have nerves of steel by now, if he agreed to review this guy's work yet again.
To be fair, Donenfeld is knowledgeable (he is behind the Wireguard VPN thing), but even smart people can go too far into a rabbit hole of theoretical things for little practical value.
One of the things userspace needs to be concerned about is forking: you don't want to share randomness with child processes as that would break cryptography security (particularly elliptic curve cryptography depends heavily on guarantee of different random values without reusing).
I know. I've had my share of people going too far to get something merged for purely theoretical reasons. More than once, developers tried to go over my head and convince the manager that their work was worth merging, by calling it a "proof of concept". The way I'm reading the situation, Donenfeld is doing the same thing here. I don't doubt that he's way more knowledgeable than me about the kernel, but if he can't even summarize his own code to Linus, instead of going on tirades with him in emails, then he needs to take a step back.
In this case, I think he has proven the reason for the main part, but there are other parts of the code that seem hard to justify due to the complexity. It is not all under question.
The performance part is easy to justify, but some of the more complex parts seem too little benefit over simpler solution. But we'll see how it turns out after some reworking for next version: [https://lore.kernel.org/lkml/[email protected]/T/#t](https://lore.kernel.org/lkml/[email protected]/T/#t)
The problem is you need to map information available to kernel into user space so that user space can make a determination if it needs to reseed its PRNG or not.
Yeah, that's what the vDSO is for. I'm not a kernel developer, but going by Linus' reaction to the PR changes, I assume it's pretty straightforward to add something to the vDSO.
It isn’t. For each thread you need to duplicate information coming from the kernel. This isn’t trivial. Linus is simply wrong in his assesment. First of all, adding the information needed wouldn’t be a 5-line patch. Second of all, the 1000+ line thing has over 400+ lines of tests.
Also,
> And seeing how the author of said code has had multiple failed attempts to do this in the past 2 years, I'd be hesitant to review yet another 1000-line commit from him.
Clearly you’ve never worked on a complex problem. It’s not unusual for a patchset to take years before it gets merged. I’ve worked on CMA which took about two years and is now (or at least was) widely used in embedded devices. Those aren’t ‘failed attempts.’ It’s a normal review process.
> For each thread you need to duplicate information coming from the kernel.
You mean duplicate the memory, or duplicate the whole existing rng kernel code? Because these are completely different things.
> Linus is simply wrong in his assesment.
My instinct says he's not that wrong, but it's his job to be skeptical, as long as a PR comes to him without any additional explanation.
> the 1000+ line thing has over 400+ lines of tests
I feel like this makes it worse. It's just a random number generator function, right? A single line of code added to an existing unit test would suffice. Or are those tests testing for purely theoretical stuff too?
> Clearly you’ve never worked on a complex problem. It’s not unusual for a patchset to take years before it gets merged. I’ve worked on CMA which took about two years and is now (or at least was) widely used in embedded devices. Those aren’t ‘failed attempts.’ It’s a normal review process.
I don't think moving some rng code from the kernel to the vDSO is supposed to be that much of a complex problem. Some developers just like to complicate problems for no reason, and it's quite easy to tell when they do that, even before reviewing their code.
> You mean duplicate the memory, or duplicate the whole existing rng kernel code?
Map all the necessary data into vDSO.
> as long as a PR comes to him without any additional explanation.
What are you talking about?
> It's just a random number generator function, right?
No. The PRNG is not the interesting part. Communicating when PRNG needs to be reseeded without doing a syscall is.
> I don't think moving some rng code from the kernel to the vDSO is supposed to be that much of a complex problem.
Alas, your tohughts don’t make it a reality. If you don’t understand the problem it’s easy to think the problem is simple.
> it's quite easy to tell when they do that, even before reviewing their code.
As this patchest demonstrate, it isn’t.
> Map all the necessary data into vDSO.
That's usually a single API/system call. And maybe not even that, since the vDSO is already a map of kernel memory into user memory. At most, some mapping directive would have to be added somewhere to get the kernel to map the whole thing into the vDSO.
> Communicating when PRNG needs to be reseeded without doing a syscall is.
So just map the syscall into the vDSO. Why even "communicate" anything? Is the existing kernel-side seeding code that complex, that you just can't find a simple way to reuse it without writing 600 lines of code? I highly doubt it.
> If you don’t understand the problem it’s easy to think the problem is simple.
I'm just going by Linus' intuition here, and I'm sure that he does understand the problem way better than you or I.
> As this patchest demonstrate, it isn’t.
You can demonstrate a whole lot of stuff with even more complex patches. But: "We don't add stuff just because we can. We need to have a damn good reason for it".
Thanks for the link. I was wondering what convinced him to go back to it. (As article update omitted just that.)
> **On Thu, 4 Jul 2024 at 11:57, Jason A. Donenfeld wrote:**
> I really do not want to expose random.c internals, and then deal with
> the consequences of breaking user code that relied on that. The fake
> entropy count API was already a nightmare to move away from. And I
> think there's tremendous value in letting users use the kernel's
> *exact algorithm*, whatever it happens to be, without syscall
> overhead. Plus, this means further proliferation of bad userspace
> RNGs. So I think the deal is a bad one.
Torvalds is frustrated at things that seem overly complicated:
[https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/](https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/)
He is more satisfied after some changes have been made:
[https://lore.kernel.org/all/CAHk-=wg0qkgpNtm\[email protected]/](https://lore.kernel.org/all/CAHk-=wg0qkgpNtm_OL-evArZxenQyJtk4BG0fVPGYqoooP6+Cw@mail.gmail.com/)
Mapping random number generation into a shared object in the kernel shaves a few ticks off of the overhead, but also adds a shit show argument of math nerds to the project.
Edit: accuracy
Exactly. Making the system call is heavier than a plain function call in a process due to different address spaces and so on which adds some overhead to the call.
vDSO is all about mapping the kernel functionality into the process so that it can avoid the overhead of a system call.
This is interesting for things like servers that can need a lot of calls for incoming connections and so on. And the point of having different random numbers is so that you can't calculate one cryptokey from another.
And getrandom() is already in kernel, where it has access to various entropy sources. Currently processes access it via system calls.
This is why I love Linux. We get to see behind the curtain. Why decisions are made and the thought process going into them. Linus is just out there giving us his uncensored opinion for all of us to see.
If the kernel can offer me one dose of really good entropy, there are \*plenty\* of ways of turning that into fast, high quality random values (e.g., NIST SP800-90). I support Linus on this one.
vDSO implementation is not replacing the in-kernel getrandom(), but adds support calling it faster.
Normally system calls need a context switch, which is pretty heavy (process memory is not same as kernel memory and so on).
vDSO is a way to map kernel functions into user processes so that those heavy parts can be omitted. gettimeofday() is often quoted as an example that is used often. This work is about adding similar mapping for getrandom().
So it isn't about new way of \*generating\* random numbers, but having a faster \*access\* to kernel so that people won't need to try to roll their own.
The people who need cryptographically secure random numbers faster than `/dev/urandom` or their cryptography library can provide are already not the vast majority of users.
By and large, the people asking for this are generally the people writing cryptography libraries, and there's long standing frustration by the kernel developers with them misusing randomness APIs because they only want "the really good random numbers".
your response is irrelevant to what you're trying to respond to. Friendly advice, it's perfectly fine to be silent when you see something out of your expertise.
For the record, linux in-kernel drbg is not and will never be FIPS (namely NIST SP800-90A)-compliant. So if you need said compliance then you're forced to use some userspace solution, for example the one from openssl. Not to mention similar standards from other countries.
So Donenfeld's attempts to get rid of userspace drbgs are futile.
Out of curiosity, is there an intrinsic reason the kernel DRBG could never be FIPS compliant, or is it just that there's no desire for it from the kernel team but some vendor could ship a modified kernel with a FIPS-compliant DRBG if they put the work in?
To me it's the issue of the patch author. He should be able to demonstrate some examples in the userpace code that would be benefitting from this vDSO patch without an effort.
I can see arguments for both sides, although I don't quite get the fixation on using vDSO for this. With things like io_uring I would think an alternate approach could be to write a kernel module that can supply user space with a fast rng buffer pool that the kernel can reset at any time (on migrations), so there seem to be ways to get this functionality without bloating the kernel core (granted with the disadvantage that user space that needs that performance would have to use a different api than getrandom)...
Please read the entire thread ....every single message to get the essence...and don't skim through , I did the hard work for you....enjoy!
[https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/](https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/)
Not saying he is or isn't a prick, but uh....he's the original creator, and lead maintainer of *the most widely used operating system on the planet*. Simply based on results, there's pretty good evidence he does, in fact, know a thing or two.
"We don't add stuff "just because we can". We need to have a damn good reason for it" I 100% agree with this .
[удалено]
For what it's worth, this is the approach OpenBSD has taken; they made a decent random number generator and highly encourage people to use it over rolling their own. In addition, because so many OpenBSD subsystems leverage it, the entropy is rather high.
Thinking that the entropy is high because many processes share a psuedo-random function sounds less like an endorsement of its security and more like a prediction of a related side channel attack several years from now.
but on the other hand, can you guarantee that there wont be issues from devs implementing their own? I can't remember where I read it, but there was an example recently of someone pulling from a random spot in memory for entropy, which sat there for years, and then other devs came later on and asked "why are they pulling bytes from this random spot?" the consensus was that it was a mistake and they changed it... and it broke a lot of stuff. Although the Linux kernel has to be a LOT more picky about what they add otherwise things could quickly become a giant mess, and once it is added, there is no good chance of removing it whether it sucks or not.
Was it really just a random spot in memory? ... Or was it pseudorandom?
I don't know if this is the case you were thinking of, as it's not terribly recent, but this was the cause of [Debian Security Advisory 1571-1][d] in 2008. An OpenSSL developer used an uninitialized variable as a source of randomness (a pretty bad idea, as the contents often aren't very random) and failed to document what they were doing (a further bad idea), and a Debian maintainer decided to "fix" the code (yet another bad idea) so that static analysers would stop complaining about it. It meant the current process ID was the only source of randomness, and that keys generated on Debian (and related) systems for the past two years had to be considered compromised. More info [here][comm]. All round, it was pretty inept behaviour from both the OpenSSL developer (why on earth did they use such a stupid source of randomness, and fail to document it?) and the Debian maintainer (why on earth were they fiddling with a cryptographic library they didn't understand?). [d]: https://lists.debian.org/debian-security-announce/2008/msg00152.html [comm]: https://www.schneier.com/blog/archives/2008/05/random_number_b.html
Thanks! thats what it was. I knew I was misremembering it.
For what it's worth, the common approach in GNU/Hurd was to symlink /dev/random to /bin/emacs/ They did explain that its a bad idea though.
Doesn't entropy decrease with use?
No.
[getrandom(2)](https://man7.org/linux/man-pages/man2/getrandom.2.html) is this already. This patch wants to add the in-kernel variant of getrandom() into the vDSO - a way for userspace applications to more-or-less directly call kernel functions as a means to speed the applications up (by skipping the otherwise necessary and expensive user-to-kernel-to-user context switch). Linus is upset that there are no real world users that *need* that kind of speed for random number generation that can't use their own userspace RNG with entropy streamed from getrandom(2). This code adds a tremendous amount of complexity and maintenance burden.
thanks for that
From what I understood he said something about it should be handled in the userland rather than the kernel and also that it has no much of a use case
> Same, but why not provide an easy way to get random bytes for the average dev that would otherwise use epoch or some other similarly dumb thing? I think you misunderstand the context. This is not about the question "Should the Linux kernel have an API for random numbers?" The Linux kernel has that already. This is specifically about the vDSO, which is an implementation detail on how the Linux kernel API is being used. Not if the feature is there at all.
The average dev should be using whatever the recommended api is for their language.
AFAIK there is already one random string for this purpose. Edit: IIRC in a different place, each program gets a random value to start with.
Can someone explain why the kernel space is capable of generating random numbers faster in the first place
It isn't. The argument put forth in favor of the patch is that the kernel is in a better position to seed its prng when required — such as after a VM is forked. In this situation, a userspace prng that periodically seeded with getrandom() could potentially duplicate random numbers until the next seed is drawn, but atm using getrandom() directly incurs syscall overhead which may have an unacceptable performance penalty.
> may have an unacceptable performance penalty. Linus's main qualm is that "may have" is too abstract. There's no documented cases of the performance penalty being actually unacceptable in practice.
Although it's worth noting that later on in the thread, someone highlights a bug report in Chrony where this is causing an unacceptable performance penalty.
i has never thought of the use of hardware seed in VM while using it in other places simultaneously
Hopefully someone can answer better than I can: Basically the kernel has access to a hardware RNG(on most cpus, but not all) with greater entropy and randomness than is usually achieved in a straight software solution. They want to make it part of vdso so that you can bypass the normal syscall overhead. I actually think it’s a good idea. Edit: I just reread the article and Linus is concerned with adding this because he thinks it’s too hard to make different consumers happy and it provides too little value. He also doesn’t want to maintain it. I guess I can get on board with that from an architecture standpoint.
It's actually wrong. All software has access to hardware RNG (on modern x86 CPUs) via rdrand instruction, but it only produces up to 8 bytes of randomness per execution and is relatively slow. It is used to "seed" a PRNG based on chacha stream cipher which will produce unpredictable sequences much faster. This is what kernel level RNG does. The two benefits it has are running mostly uninterrupted (that gives a bit more performance) and built-in automatic periodic mixing of entropy sources like rdrand, system timer variance, net traffic statistics, etc. In user space you will have to find and mix extra entropy sources yourself, but it's doable. You are just more likely to mess up the implementation. If we are talking about real hardware RNGs, not just TPM or CPU, they are available via hw_random interface from user space.
rdrand is broken on older AMD's
The kernel utilities for getting random number is usually only used for seeding a PRNG that is then used fully in user-land to get more random data. So if the user-land code is written by someone that knows what they are doing, it should perform only 1 call to kernel random utilities in its entire lifetime. So the entire performance argument make no sense in my view.
The issue is that if you're, for example, cloning a VM, one call per application lifetime isn't enough. The application doesn't know it's been cloned, but the kernel does, so application code risks, for example, generating duplicate identifiers.
I wonder why the patch author doesn't mention it, it could've been bugfix patch if he demonstrated VM generating duplicate identifiers.
The patch author doesn't mention it, although there are some comments by Linus that suggest he's aware of it as an argument but doesn't find it that convincing. There are some subsequent replies by others that do explicitly mention this use case.
> it should perform only 1 call to kernel random utilities in its entire lifetime. So the entire performance argument make no sense in my view. I hope that you mean once per software application rather than user? Using same seed everywhere is dangerous.
yes 1 call by application.
vDSO happy paths are in user-space.
I think [this article](https://lwn.net/Articles/919008/) explains the problem much better. There's also [another article](https://lwn.net/SubscriberLink/980447/8719e2f48e7b8d70/) that's actually about this more recent patch set
An update notes he backtracks here: https://lore.kernel.org/all/CAHk-=wjCmw1L42W-o=pW7_i=nJK5r0_HFQTWD_agKWGt4hE7JQ@mail.gmail.com/
"Bah. I guess I'll have to walk through the patch series once again. I'm still not thrilled about it. But I'll give it another go." Linus
To add a bit of context, this was in response to Linus asking a normal-ish question, Jason responding, and Linus calling BS. But then Jason Uno-recersed Linus and got this concession. > > Jason. This smells. It's BS. > It's not BS. And that's not a real argument from you, but rather is something else.
He didn't just call it BS. Full quote: > Jason. This smells. It's BS. > Christ, let's make a deal: do a five-liner patch that adds the generation number to the vdso data, and basically document it as a "the kernel thinks you need to reseed your buffers using getrandom" flag. > And *if* it turns out in the future that there is then any major reason why that doesn't work, I'll take the 1000+ line thing, ok? > Deal? I too would be pretty adamant about a 1000-line patch for something that could've been done in 5 lines. The code for rng is already there in the kernel, so I'm guessing that just re-using it in the vDSO shouldn't require 1000 more lines of code. And seeing how the author of said code has had multiple failed attempts to do this in the past 2 years, I'd be hesitant to review yet another 1000-line commit from him. Linus must have nerves of steel by now, if he agreed to review this guy's work yet again.
To be fair, Donenfeld is knowledgeable (he is behind the Wireguard VPN thing), but even smart people can go too far into a rabbit hole of theoretical things for little practical value. One of the things userspace needs to be concerned about is forking: you don't want to share randomness with child processes as that would break cryptography security (particularly elliptic curve cryptography depends heavily on guarantee of different random values without reusing).
I know. I've had my share of people going too far to get something merged for purely theoretical reasons. More than once, developers tried to go over my head and convince the manager that their work was worth merging, by calling it a "proof of concept". The way I'm reading the situation, Donenfeld is doing the same thing here. I don't doubt that he's way more knowledgeable than me about the kernel, but if he can't even summarize his own code to Linus, instead of going on tirades with him in emails, then he needs to take a step back.
In this case, I think he has proven the reason for the main part, but there are other parts of the code that seem hard to justify due to the complexity. It is not all under question. The performance part is easy to justify, but some of the more complex parts seem too little benefit over simpler solution. But we'll see how it turns out after some reworking for next version: [https://lore.kernel.org/lkml/[email protected]/T/#t](https://lore.kernel.org/lkml/[email protected]/T/#t)
The problem is you need to map information available to kernel into user space so that user space can make a determination if it needs to reseed its PRNG or not.
Yeah, that's what the vDSO is for. I'm not a kernel developer, but going by Linus' reaction to the PR changes, I assume it's pretty straightforward to add something to the vDSO.
It isn’t. For each thread you need to duplicate information coming from the kernel. This isn’t trivial. Linus is simply wrong in his assesment. First of all, adding the information needed wouldn’t be a 5-line patch. Second of all, the 1000+ line thing has over 400+ lines of tests. Also, > And seeing how the author of said code has had multiple failed attempts to do this in the past 2 years, I'd be hesitant to review yet another 1000-line commit from him. Clearly you’ve never worked on a complex problem. It’s not unusual for a patchset to take years before it gets merged. I’ve worked on CMA which took about two years and is now (or at least was) widely used in embedded devices. Those aren’t ‘failed attempts.’ It’s a normal review process.
> For each thread you need to duplicate information coming from the kernel. You mean duplicate the memory, or duplicate the whole existing rng kernel code? Because these are completely different things. > Linus is simply wrong in his assesment. My instinct says he's not that wrong, but it's his job to be skeptical, as long as a PR comes to him without any additional explanation. > the 1000+ line thing has over 400+ lines of tests I feel like this makes it worse. It's just a random number generator function, right? A single line of code added to an existing unit test would suffice. Or are those tests testing for purely theoretical stuff too? > Clearly you’ve never worked on a complex problem. It’s not unusual for a patchset to take years before it gets merged. I’ve worked on CMA which took about two years and is now (or at least was) widely used in embedded devices. Those aren’t ‘failed attempts.’ It’s a normal review process. I don't think moving some rng code from the kernel to the vDSO is supposed to be that much of a complex problem. Some developers just like to complicate problems for no reason, and it's quite easy to tell when they do that, even before reviewing their code.
> You mean duplicate the memory, or duplicate the whole existing rng kernel code? Map all the necessary data into vDSO. > as long as a PR comes to him without any additional explanation. What are you talking about? > It's just a random number generator function, right? No. The PRNG is not the interesting part. Communicating when PRNG needs to be reseeded without doing a syscall is. > I don't think moving some rng code from the kernel to the vDSO is supposed to be that much of a complex problem. Alas, your tohughts don’t make it a reality. If you don’t understand the problem it’s easy to think the problem is simple. > it's quite easy to tell when they do that, even before reviewing their code. As this patchest demonstrate, it isn’t.
> Map all the necessary data into vDSO. That's usually a single API/system call. And maybe not even that, since the vDSO is already a map of kernel memory into user memory. At most, some mapping directive would have to be added somewhere to get the kernel to map the whole thing into the vDSO. > Communicating when PRNG needs to be reseeded without doing a syscall is. So just map the syscall into the vDSO. Why even "communicate" anything? Is the existing kernel-side seeding code that complex, that you just can't find a simple way to reuse it without writing 600 lines of code? I highly doubt it. > If you don’t understand the problem it’s easy to think the problem is simple. I'm just going by Linus' intuition here, and I'm sure that he does understand the problem way better than you or I. > As this patchest demonstrate, it isn’t. You can demonstrate a whole lot of stuff with even more complex patches. But: "We don't add stuff just because we can. We need to have a damn good reason for it".
Thanks for the link. I was wondering what convinced him to go back to it. (As article update omitted just that.) > **On Thu, 4 Jul 2024 at 11:57, Jason A. Donenfeld wrote:**
> I really do not want to expose random.c internals, and then deal with
> the consequences of breaking user code that relied on that. The fake
> entropy count API was already a nightmare to move away from. And I
> think there's tremendous value in letting users use the kernel's
> *exact algorithm*, whatever it happens to be, without syscall
> overhead. Plus, this means further proliferation of bad userspace
> RNGs. So I think the deal is a bad one.
Eli5 anyone?
Torvalds is frustrated at things that seem overly complicated: [https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/](https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/) He is more satisfied after some changes have been made: [https://lore.kernel.org/all/CAHk-=wg0qkgpNtm\[email protected]/](https://lore.kernel.org/all/CAHk-=wg0qkgpNtm_OL-evArZxenQyJtk4BG0fVPGYqoooP6+Cw@mail.gmail.com/)
Mapping random number generation into a shared object in the kernel shaves a few ticks off of the overhead, but also adds a shit show argument of math nerds to the project. Edit: accuracy
Sorry, isn't the point of having it in the vDSO that you don't have to make a system call?
Exactly. Making the system call is heavier than a plain function call in a process due to different address spaces and so on which adds some overhead to the call. vDSO is all about mapping the kernel functionality into the process so that it can avoid the overhead of a system call. This is interesting for things like servers that can need a lot of calls for incoming connections and so on. And the point of having different random numbers is so that you can't calculate one cryptokey from another. And getrandom() is already in kernel, where it has access to various entropy sources. Currently processes access it via system calls.
This is why I love Linux. We get to see behind the curtain. Why decisions are made and the thought process going into them. Linus is just out there giving us his uncensored opinion for all of us to see.
Absolutely. And even better, if you don't agree with the thought process, you can implement an alternative yourself, at least theoretically.
If the kernel can offer me one dose of really good entropy, there are \*plenty\* of ways of turning that into fast, high quality random values (e.g., NIST SP800-90). I support Linus on this one.
vDSO implementation is not replacing the in-kernel getrandom(), but adds support calling it faster. Normally system calls need a context switch, which is pretty heavy (process memory is not same as kernel memory and so on). vDSO is a way to map kernel functions into user processes so that those heavy parts can be omitted. gettimeofday() is often quoted as an example that is used often. This work is about adding similar mapping for getrandom(). So it isn't about new way of \*generating\* random numbers, but having a faster \*access\* to kernel so that people won't need to try to roll their own.
The vast majority of people should not do this: https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
The people who need cryptographically secure random numbers faster than `/dev/urandom` or their cryptography library can provide are already not the vast majority of users. By and large, the people asking for this are generally the people writing cryptography libraries, and there's long standing frustration by the kernel developers with them misusing randomness APIs because they only want "the really good random numbers".
What's an example of abusing said API
Using /dev/random instead of /dev/urandom, back before they got merged
What was the difference
/dev/random was blocking, /dev/urandom was not. There's some good info on it at https://www.2uo.de/myths-about-urandom/
your response is irrelevant to what you're trying to respond to. Friendly advice, it's perfectly fine to be silent when you see something out of your expertise. For the record, linux in-kernel drbg is not and will never be FIPS (namely NIST SP800-90A)-compliant. So if you need said compliance then you're forced to use some userspace solution, for example the one from openssl. Not to mention similar standards from other countries. So Donenfeld's attempts to get rid of userspace drbgs are futile.
Out of curiosity, is there an intrinsic reason the kernel DRBG could never be FIPS compliant, or is it just that there's no desire for it from the kernel team but some vendor could ship a modified kernel with a FIPS-compliant DRBG if they put the work in?
He is a true minimalist, it seems. Bloat Functions are still Bloat.
He's a lot more personable since the Linux foundation added curse filters to his email.
I wonder who actually needs it and what for.
Linus does as well. That's the issue
To me it's the issue of the patch author. He should be able to demonstrate some examples in the userpace code that would be benefitting from this vDSO patch without an effort.
I agree. I get that a theoretical improvement is nice, but why to produce more code to be maintained, without any real benefit?
I can see arguments for both sides, although I don't quite get the fixation on using vDSO for this. With things like io_uring I would think an alternate approach could be to write a kernel module that can supply user space with a fast rng buffer pool that the kernel can reset at any time (on migrations), so there seem to be ways to get this functionality without bloating the kernel core (granted with the disadvantage that user space that needs that performance would have to use a different api than getrandom)...
Context? Article doesn’t explain much
Please read the entire thread ....every single message to get the essence...and don't skim through , I did the hard work for you....enjoy! [https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/](https://lore.kernel.org/all/CAHk-=wgC5tWThswb1EO5W75wWL-OhB0fqrnF9nR+Fnsgjp-NfA@mail.gmail.com/)
Linus is a prick and thinks he knows more than everyone else . He doesn’t
Not saying he is or isn't a prick, but uh....he's the original creator, and lead maintainer of *the most widely used operating system on the planet*. Simply based on results, there's pretty good evidence he does, in fact, know a thing or two.