points by JdeBP 7 years ago

The instruction is signalling success, but returning FFFFFFFFFFFFFFFF as the random value.

* https://github.com/systemd/systemd/issues/11810#issuecomment...

H. Peter Anvin's educated guess was that some MSR flag, that has the effect of controlling this instruction, is not being saved and restored in the processor across a suspend, and the result is a processor state where it signals that the instruction is succeeding but it is not actually returning random values.

* https://bugzilla.kernel.org/show_bug.cgi?id=85911#c4

lelf 7 years ago

> The instruction is signalling success

Let’s wait for clarifications how that person has done the tests.

However: the bug is about systemd failing to get entropy, not getting nonsense entropy.

  • JdeBP 7 years ago

    How xe was doing this was in fact explained in the comment hyperlinked right at the start of this page, and H. Peter Anvin was thinking about this over 4 years ago. But for the doubters Vladislav has already reiterated the point.

    * https://github.com/systemd/systemd/issues/11810#issuecomment...

    There is no "however". This bug is about code that is, according to the AMD doco, using the instruction correctly; but that is, because the AMD processor has this possible state after a suspend+resume, getting all-ones as its random data, thereby causing ID collisions in a fairly wide range of possible things from freshly re-generated machine IDs to journal file header block IDs, and including unit invocation IDs.

    * https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...

    * https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...

    * https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...

    This indicates that a "should be fine" in another comment is not in fact true. (-:

    * https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...

    • zaroth 7 years ago

      The Bugzilla report seemed to indicate that AMD was returning an error code, because OpenSSL was failing to generate a key, not generating a bad key?

      Why would OpenSSL fail visibly if the API was returning success but with non-random data?

      https://bugzilla.redhat.com/show_bug.cgi?id=1150286

      • int_19h 7 years ago

        If you look closely at one of the error messages, it says "too many iterations", in what looks like a random generator. I wonder if at some point it has to iterate to get a number different from another one, and it just gets an endless stream of identical values?

        • zaroth 7 years ago

          I can’t imagine the code is checking the returned value for uniqueness after seeing a SUCCESS code, and iterating in the hopes that becomes less true.

          That would be quite something to read the comment on;

          // Here we check to be sure the Earth is not flat

          ...

          // Seeing that the Earth is indeed flat, we will iterate in this absurdity some more in the hopes it rounds out eventually

          • int_19h 7 years ago

            Suppose you need to generate several unique 32-bit IDs for something?