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.
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 undefined. 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 deterministic. The MVCL and CLCL instructions 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. A fairly small modification to the semantics would have solved this potential problem: Upon completion of the operation, put final address and count into the registers just as any interrupt at the end would have. Further remember in the interrupt packet that an MVCL or CLCL was in progress and avoid going back to memory, which might have been modified by the MVCL to recall what you were doing. These changes would have cost a small performance hit on some of the models.
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.
Even when there is no possible exploitation of the noise, simplicity of arguments may justify the expense of determinism.