4 ms·

>1. RDRAND returns -1 (and sets the carry bit meaning it thinks -1 is a random number). Supposedly this will be fixed in a BIOS update (which makes me think it'

>1. RDRAND returns -1 (and sets the carry bit meaning it thinks -1 is a random number). Supposedly this will be fixed in a BIOS update (which makes me think it's an intended mode wrongly turned on... a backdoor?) Yet more evidence not to trust hardware random number generators.

userbinator 7y ago
I'm very surprised that something like that even makes it into production. You'd think processor manufacturers would have an extensive set of test cases, at least one for each instruction... I remember reading somewhere that, for a long time, Intel's "test cases" basically consisted of all the operating systems they could find, going back to MS-DOS 1.0 and including some more obscured ones, as well as tons of other third-party software. Unfortunately it seems this new generation no longer follows the "NEVER break backwards compatibility" principle that made the PC such a great platform, and as a result we're seeing hardware/software/firmware that's increasingly buggy and divergent. It used to be the case that if a new processor couldn't run existing software (even that which depended on undocumented but constant behaviour) unmodified, it was a fatal flaw.
- im_down_w_otp 7y ago
  They have way, way more than test cases. The logic synthesis, simulation, verification, and validation capabilities of top tier EDA tools are incredible. The problem is as it always is with these kinds of things. They help assure that you can measure your model and your implementation of that model. They're much less capable of determining you've got the right model to begin with. That part is still up to the humans. The state of commonplace capabilities for testing and verification of software is extremely far behind that of hardware. For a variety of economic, cultural, and use case incentives reasons.
- pjc50 7y ago
  Everything on a CPU is subject to heavy validation .. but I bet the random number generator is exempt, because by definition it's not deterministic. It's more like a peripheral "listening" to randomness. https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf https://www.amd.com/system/files/TechDocs/amd-random-number-... > "The RNG uses 16 separate ring oscillator chains as a noise source. Each chain consists of a different prime number of inverters in a free-running configuration which capture natural clock jitter" So it's (deliberately) dependent on natural manufacturing variation in the silicon, and in any deterministic simulator won't produce random numbers. It also takes a while to start; it's possible that the startup conditions are bad such that "a while" turns out to be "forever".
  - mulmen 7y ago
    Probably still worth checking that it doesn't return -1 every time.
    - NullPrefix 7y ago
      Infinity of -1's is a valid random sequence, just saying.
ezoe 7y ago
This should teach systemd developers and other idiots who blindly use rdrand a lesson not to trust it.
- IntelMiner 7y ago
  Have you read systemd's code comments regarding rdrand? It's quite a reasonable explanation
  - ezoe 7y ago
    I have just read it. Well I have to say it's quite a reasonable. https://github.com/systemd/systemd/blob/f90bcf8679e8708788290519dc09371e60c6fc82/src/basic/random-util.c#L34 https://github.com/systemd/systemd/blob/f90bcf8679e870878829...
    - jammygit 7y ago
      "In such an environment using getrandom() synchronously means we'd block the entire system boot-up until the pool is initialized, i.e. very long." How long is very long? 100ms, or 10s?
      - megous 7y ago
        "It is very common that initialization of the random pool takes a longer time (up to many minutes..." And it's my experience, too. It's one reason to install something like haveged. I had boot delays in the range of minutes, without it.
      - terom 7y ago
        Debian buster VM on an old CPU without RDRAND takes about 5 minutes for the kernel crng init to complete and for sshd to start accepting connections. Stracing the sshd process shows that it's indeed blocked on `getrandom()`. In some ways, it's very much WONTFIX because something like sshd might actually need the entropy. I'm glad that systemd has proper workarounds implemented so that the machine actually boots out of the box, though.

userbinator 7y ago

I'm very surprised that something like that even makes it into production. You'd think processor manufacturers would have an extensive set of test cases, at least one for each instruction... I remember reading somewhere that, for a long time, Intel's "test cases" basically consisted of all the operating systems they could find, going back to MS-DOS 1.0 and including some more obscured ones, as well as tons of other third-party software. Unfortunately it seems this new generation no longer follows the "NEVER break backwards compatibility" principle that made the PC such a great platform, and as a result we're seeing hardware/software/firmware that's increasingly buggy and divergent. It used to be the case that if a new processor couldn't run existing software (even that which depended on undocumented but constant behaviour) unmodified, it was a fatal flaw.

im_down_w_otp 7y ago
They have way, way more than test cases. The logic synthesis, simulation, verification, and validation capabilities of top tier EDA tools are incredible. The problem is as it always is with these kinds of things. They help assure that you can measure your model and your implementation of that model. They're much less capable of determining you've got the right model to begin with. That part is still up to the humans. The state of commonplace capabilities for testing and verification of software is extremely far behind that of hardware. For a variety of economic, cultural, and use case incentives reasons.
pjc50 7y ago
Everything on a CPU is subject to heavy validation .. but I bet the random number generator is exempt, because by definition it's not deterministic. It's more like a peripheral "listening" to randomness. https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf https://www.amd.com/system/files/TechDocs/amd-random-number-... > "The RNG uses 16 separate ring oscillator chains as a noise source. Each chain consists of a different prime number of inverters in a free-running configuration which capture natural clock jitter" So it's (deliberately) dependent on natural manufacturing variation in the silicon, and in any deterministic simulator won't produce random numbers. It also takes a while to start; it's possible that the startup conditions are bad such that "a while" turns out to be "forever".
- mulmen 7y ago
  Probably still worth checking that it doesn't return -1 every time.
  - NullPrefix 7y ago
    Infinity of -1's is a valid random sequence, just saying.

ezoe 7y ago

This should teach systemd developers and other idiots who blindly use rdrand a lesson not to trust it.

IntelMiner 7y ago
Have you read systemd's code comments regarding rdrand? It's quite a reasonable explanation
- ezoe 7y ago
  I have just read it. Well I have to say it's quite a reasonable. https://github.com/systemd/systemd/blob/f90bcf8679e8708788290519dc09371e60c6fc82/src/basic/random-util.c#L34 https://github.com/systemd/systemd/blob/f90bcf8679e870878829...
  - jammygit 7y ago
    "In such an environment using getrandom() synchronously means we'd block the entire system boot-up until the pool is initialized, i.e. very long." How long is very long? 100ms, or 10s?
    - megous 7y ago
      "It is very common that initialization of the random pool takes a longer time (up to many minutes..." And it's my experience, too. It's one reason to install something like haveged. I had boot delays in the range of minutes, without it.
    - terom 7y ago
      Debian buster VM on an old CPU without RDRAND takes about 5 minutes for the kernel crng init to complete and for sshd to start accepting connections. Stracing the sshd process shows that it's indeed blocked on `getrandom()`. In some ways, it's very much WONTFIX because something like sshd might actually need the entropy. I'm glad that systemd has proper workarounds implemented so that the machine actually boots out of the box, though.