4 ms·

> Poettering's stance seems so oblivious (get a better hardware or fix from manufacturer) or just disable rdrand.

bcrl 6y ago
Or just use a piece of software for which fragility isn't the modus operandi of the author. Oh wait, we don't have that choice in any of the mainstream distros.
- segfaultbuserr 6y ago
  As I explained in this comment, RDRAND was a reasonable decision back then. https://news.ycombinator.com/item?id=25737894 https://news.ycombinator.com/item?id=25737894
  - bcrl 6y ago
    It's the fragility that I'm opposed to. As a kernel developer, your code must be robust against all failure modes. systemd is not robust against all failure modes. I don't see why he's getting a pass for writing fragile code.
    - segfaultbuserr 6y ago
      > As a kernel developer, your code must be robust against all failure modes. Systemd implemented RDRAND precisely because the kernel was previously not robust against all failure modes regarding to /dev/urandom - early boot may block indefinitely if there's a lack of adequate inputs (the fallback in-kernel jitter entropy collector was introduced many years later, in 2019). Also, the failure of RDRAND was virtually unheard of [0] at that time when that decision was made. It's why I said the decision was reasonable back then [1]. I agree that the context has changed after AMD's first RDRAND incident and that decision has became less reasonable. [0] At least for non-crypto purposes, like systemd's uses. Compromised RDRAND is always a concern among cryptographers, but totally broken RDRAND was not. [1] BTW, I bet implementing an entropy gathering code and a randomness algorithm in systemd would probably cause greater amount of criticism.
      - bcrl 6y ago
        RDRAND is not the problem. The design failure is in assuming collisions don't exist. That's a poor design decision made by the developer that is directly the responsibility of the developer. If this was a one-off bug in systemd, it could get a pass, but it isn't a one-off. Try to boot a Linux system using systemd when something is just slightly off, like one block device that's normally available is missing or when networking doesn't come up. systemd does not handle failures well, and it doesn't handle them because the main developer makes no effort to test failure modes. This incident is yet another example of this pattern of development style. When I write code, I have to make an effort to test what happens during unexpected failures. I expect the developer of the most critical component to booting a modern Linux system to do the same.
        segfaultbuserr 6y ago
        > RDRAND is not the problem. [...] If this was a one-off bug in systemd, it could get a pass, but it isn't a one-off. Fair enough.

bcrl 6y ago

Or just use a piece of software for which fragility isn't the modus operandi of the author. Oh wait, we don't have that choice in any of the mainstream distros.

segfaultbuserr 6y ago
As I explained in this comment, RDRAND was a reasonable decision back then. https://news.ycombinator.com/item?id=25737894 https://news.ycombinator.com/item?id=25737894
- bcrl 6y ago
  It's the fragility that I'm opposed to. As a kernel developer, your code must be robust against all failure modes. systemd is not robust against all failure modes. I don't see why he's getting a pass for writing fragile code.
  - segfaultbuserr 6y ago
    > As a kernel developer, your code must be robust against all failure modes. Systemd implemented RDRAND precisely because the kernel was previously not robust against all failure modes regarding to /dev/urandom - early boot may block indefinitely if there's a lack of adequate inputs (the fallback in-kernel jitter entropy collector was introduced many years later, in 2019). Also, the failure of RDRAND was virtually unheard of [0] at that time when that decision was made. It's why I said the decision was reasonable back then [1]. I agree that the context has changed after AMD's first RDRAND incident and that decision has became less reasonable. [0] At least for non-crypto purposes, like systemd's uses. Compromised RDRAND is always a concern among cryptographers, but totally broken RDRAND was not. [1] BTW, I bet implementing an entropy gathering code and a randomness algorithm in systemd would probably cause greater amount of criticism.
    - bcrl 6y ago
      RDRAND is not the problem. The design failure is in assuming collisions don't exist. That's a poor design decision made by the developer that is directly the responsibility of the developer. If this was a one-off bug in systemd, it could get a pass, but it isn't a one-off. Try to boot a Linux system using systemd when something is just slightly off, like one block device that's normally available is missing or when networking doesn't come up. systemd does not handle failures well, and it doesn't handle them because the main developer makes no effort to test failure modes. This incident is yet another example of this pattern of development style. When I write code, I have to make an effort to test what happens during unexpected failures. I expect the developer of the most critical component to booting a modern Linux system to do the same.
      - segfaultbuserr 6y ago
        > RDRAND is not the problem. [...] If this was a one-off bug in systemd, it could get a pass, but it isn't a one-off. Fair enough.