1. That's not random number generation code, that's code that uses random number generators.

2. What algorithm? It's just RDRAND.

3. Where else would you pass them?

4. What do you mean 'they'? CPU manufacturers?

You might also be interested in this comment: https://github.com/systemd/systemd/blob/bcac754d66374782a85a...

Not sure if you followed the links I posted, but as Poettering said, the problem is that there are collisions in UUIDs. UUID generation should be robust to random number collisions.

So you actually want them to wrap RDRAND in their own random number generator?

> UUID generation should be robust to random number collisions.

The UUID standards say that nowhere at all, it is only acknowledged that collisions may happen even if they are unlikely.

Purpose of UUID is to be unique, not random. There is no need to wrap RDRAND into another random generator. One can use time/counter as one part of UUID and kernel provided PRNG, e. g. getrandom(2) for another part.

> getrandom(2) for another part.

But you cannot use getrandom().

During early boot, the kernel will either block indefinitely and/or log the uninitialized urandom read as a security problem. It was the entire reason that brought systemd's rdrand code into existence.

1. Scroll up in the same file, there's a lengthy comment about it.

3. You don't. The `nordrand` argument is a kernel argument that tells the kernel to disable rdrand; so then when systemd asks the kernel if rdrand is supported the kernel says "no". The `SYSTEMD_RDRAND=0` argument is indeed a systemd argument, but it's absolutely normal to pass init arguments on the kernel command line.

4. Because hacking around hardware bugs isn't systemd's job. It's the kernel's. You shouldn't be filing a systemd bug, you should be filing a Linux bug to disable rdrand on that cpuid. Why aren't you asking why Linux wasn't able to provide a solution in 2 years?