4 ms·

It's not systemd's job to fix hardware bugs, it's the kernel's (or AMD's). The fix for the last time this happened was to mask the offending CPU IDs in the kern

It's not systemd's job to fix hardware bugs, it's the kernel's (or AMD's). The fix for the last time this happened was to mask the offending CPU IDs in the kernel's RNG from using RDRAND. systemd did have a temporary hack in place for their direct RDRAND implementation, but this current bug isn't the same (not just emitting 0 like last time, but eventually emitting duplicate values in pairs).

klmadfejno 6y ago
That doesn't seem to answer the question of why use it
- tadfisher 6y ago
  If they don't use it, the kernel does in order to initialize the entropy pool, which will also result in broken boots. To work around historically flaky kernel implementations, systemd calls RDRAND directly if it detects it needs to with a heuristic. This is why the fix for the current issue is to set both 'nordrand' and 'SYSTEMD_RDRAND=0'.
  - tedunangst 6y ago
    What happened to it's not systemd's job to fix kernel bugs?
    - tadfisher 6y ago
      I didn't type that, so I'm not sure what you're referring to. systemd is fundamentally tied to Linux and thus needs to implement workarounds from time-to-time when kernel facilities are lacking. This is complicated by the requirement that systemd continue working on older Linux versions.
- numpad0 6y ago
  It generally makes more sense to trust CPU specifications and utilize it fully, than to assume everything is tampered with and only ever use `mov`
ginko 6y ago
Even so, systemd should be able to deal with name collisions even with numbers coming from a true RNG. That causing errors is a design issue, IMO.
- johncolanduoni 6y ago
  Most cryptographic constructs you feed CSPRNG data into break spectacularly if they receive colliding data so I guess they all have design issues too. Including the TLS connection you’re typing your comment through.
- tadfisher 6y ago
  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/61bd7d1ed595a98e5fbfeb75b530539c4834f6a4/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...
  - aidenn0 6y ago
    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/bcac754d66374782a85a8de39fd543c1eaf9fa82/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/bcac754d66374782a85a...
    - tadfisher 6y ago
deleted 6y ago
[deleted]
tremon 6y ago
But it becomes systemd's job to fix/compensate for hardware bugs if they explicitly access the hardware directly instead of going through the kernel, no?
- LukeShu 6y ago
  They do go through the kernel; it asks the kernel "can I use rdrand", and the kernel says "yep, go ahead, it works on this CPU". If that's not true, and it doesn't work on the CPU, then it's the kernel's fault for lying and saying that it does.
effie 6y ago
I think it is systemd's job to make sure it works for its users, even though that requires working around HW bugs. If RDRAND is so problematic and can be not used, why use it at all? Just abstain from using it, simplify the logic and solve this class of issues once and for all.

klmadfejno 6y ago

That doesn't seem to answer the question of why use it

tadfisher 6y ago
If they don't use it, the kernel does in order to initialize the entropy pool, which will also result in broken boots. To work around historically flaky kernel implementations, systemd calls RDRAND directly if it detects it needs to with a heuristic. This is why the fix for the current issue is to set both 'nordrand' and 'SYSTEMD_RDRAND=0'.
- tedunangst 6y ago
  What happened to it's not systemd's job to fix kernel bugs?
  - tadfisher 6y ago
    I didn't type that, so I'm not sure what you're referring to. systemd is fundamentally tied to Linux and thus needs to implement workarounds from time-to-time when kernel facilities are lacking. This is complicated by the requirement that systemd continue working on older Linux versions.
numpad0 6y ago
It generally makes more sense to trust CPU specifications and utilize it fully, than to assume everything is tampered with and only ever use `mov`

ginko 6y ago

Even so, systemd should be able to deal with name collisions even with numbers coming from a true RNG. That causing errors is a design issue, IMO.

johncolanduoni 6y ago
Most cryptographic constructs you feed CSPRNG data into break spectacularly if they receive colliding data so I guess they all have design issues too. Including the TLS connection you’re typing your comment through.
tadfisher 6y ago
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/61bd7d1ed595a98e5fbfeb75b530539c4834f6a4/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...
- aidenn0 6y ago
  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/bcac754d66374782a85a8de39fd543c1eaf9fa82/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/bcac754d66374782a85a...
  - tadfisher 6y ago

deleted 6y ago

[deleted]

tremon 6y ago

But it becomes systemd's job to fix/compensate for hardware bugs if they explicitly access the hardware directly instead of going through the kernel, no?

LukeShu 6y ago
They do go through the kernel; it asks the kernel "can I use rdrand", and the kernel says "yep, go ahead, it works on this CPU". If that's not true, and it doesn't work on the CPU, then it's the kernel's fault for lying and saying that it does.

effie 6y ago

I think it is systemd's job to make sure it works for its users, even though that requires working around HW bugs. If RDRAND is so problematic and can be not used, why use it at all? Just abstain from using it, simplify the logic and solve this class of issues once and for all.