I don't understand why you believe an adversarial CPU must be deterministic simply because it says it will be.
Re:Fixing Getrandom()
by cryptonector on Tuesday October 01, 2019 @05:58PM
(#21131180)
I don't understand why you got downvoted. Even if GP meant that a CPU that is advertised as formally verified must be deterministic... the devil is in the details, and any number of bugs and undocumented features, including vulnerabilities and backdoors, can hide in a formally verified CPU that has billions of transistors.
Re:Fixing Getrandom()
by tedunangst on Tuesday October 01, 2019 @07:23PM
(#21131976)
Even if it seems deterministic now, there's no guarantee it won't become non deterministic in the future. https://ieeexplore.ieee.org/document/7546493
This is a very valid point, and there is even anecdotal evidence that operations we expect to be deterministic may not always be so.[1] Just because ADD works as documented in most scenarios doesn't mean we can verify that it will always work as documented in every scenario.
[1]: https://techreport.com/review/17732/intel-graphics-drivers-e...
The main difference is that the behavior of the rest of the CPU is deterministic, so it can be verified. When you use the ADD instruction, the output will always be the sum of its inputs; when you use the RDRAND instruction, the output comes from a black box which is supposed to mix internal non-deterministic noise sources in a non-reversible way. How can you distinguish a correct RDRAND from a malicious or broken one which generates its output in a reversible way or based on a fixed key, since the apparent output (an arbitrary number) is the same in both cases?