News for hackers. Stuff that matters.
Re:RDRAND on AMD Ryzen 9 5900X is flakey by tadfisher on Monday January 11, 2021 @03:40PM (#25736390)
That would be a non-deterministic failure case scaling to O(n) in both space and time. But it's not just UUIDs, it's also required for seeding systemd's internal hash tables, which would degrade from O(1) lookups to O(n) should an attacker exploit known RNG flaws.

So, a PRNG with a semi-decent (not perfect) entropy pool is required at boot time, and systemd needs to run in environments where seeding that pool in software could take on the order of minutes. This is why RDRAND is used to seed the pool during boot.

https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...

Re:RDRAND on AMD Ryzen 9 5900X is flakey by aidenn0 on Monday January 11, 2021 @05:22PM (#25738335)
1. UUIDs are stored somewhere so there's already O(n) space in use. Checking for collisions is only O(log n) in time.

2. Use a tree instead of a hash-table; or just use RDRAND and hope you aren't presented with malicious inputs.

The comment in the code[1] about RDRAND being sufficient for the use-case of UUIDs is empirically false. To continue to rely upon it is to insist that the rest of the world conform to your beliefs, rather than to adjust your beliefs to match the rest of the world.

1: https://github.com/systemd/systemd/blob/bcac754d66374782a85a...

Re:RDRAND on AMD Ryzen 9 5900X is flakey by tadfisher on Monday January 11, 2021 @05:48PM (#25738817)
> The comment in the code[1] about RDRAND being sufficient for the use-case of UUIDs is empirically false.

Ipse dixit. Can you provide an explanation?

Re:RDRAND on AMD Ryzen 9 5900X is flakey by aidenn0 on Monday January 11, 2021 @05:53PM (#25738935)
1. TFA

2. https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd...

3. https://linuxreviews.org/RDRAND_stops_returning_random_value...

4. There are also comments elsewhere on this page that older Intel RDRAND implementations had similar issues, but they did not cite their source.