When we try to argue about confinement from a mathematical perspective some strange issues arise.
We can hardly hope to prove that a random number generator that you run will not produce the secrets that I had hoped to confine.
At best we might hope to prove that your generator is no more likely to produce my secrets contingent on those secrets existing in a confined portion of the system.
Other Indeterminacies
The IBM 370 had a complex instruction set but it was described very carefully.
(More carefully, alas, than the current successors.)
Five of the non privileged instruction definitions explicitly stated that certain results, visible to the program, were indeterminate.
This was done to give maximum implementation latitude to the implementers of that series of machines whose performance spanned a few orders of magnitude.
The details of the individual implementations made most of the instructions determinate.
The MVCL instruction was interruptible and the state of the registers upon resumption revealed that an interruption had taken place. This could reveal, in turn, information that the program should not have.
One edition of the 370 manual, I believe, was careful to say that the indeterminate state that was revealed to the user mode program did not depend on the state of other processes. I recall the term "boundedly indeterminate" but that term has been used with other meanings among the CSP theorists.
Moral
When user mode programs run nondeterministically there is a source of noise. One man's noise may be another man's secrets.
Deterministic instruction sets are a powerful protection against covert channels.
Even when there is no possible exploitation of the noise, simplicity of arguments may justify the expense of determinism.