Re: trusting the processor chip

[norm@netcom.com (Norman Hardy)]

At 9:53 AM 4/25/96, Jeffrey C. Flynn wrote:
....
>
>It looks like I may have no other option than to give some processor some
>degree of trust. Which processor I should choose, and why that one?
....
In the days of microcode this was my best (worst?) scenario. Setting up for
fast divide has been an art long before Pentium divide fame. In microcode
you don't spend time testing for cases that you can prove won't happen.
Some obscure cases can arise only with a rare combinations of two 48 bit
operands. The microcode flaw would be to put the processor into privileged
mode even while getting the right answer. There would plausible deniability
even if the flaw were discovered. (Gosh, I didn't test for this fall thru
case because here is the proof that it can't happen.) Of course there is a
bug in the proof but no one reads proofs. This can now be exploited by
anyone that knows what division leaves the machine in privileged state.

This is an attack on those systems that are rated to run untrusted machine
code, using privileged mode code to limit the operation of the untrusted
code.

Only one person is necessary to pull this off. He must be trusted to
produce microcode and the implementer of the divide algorithm. Test code
will not find the transition to privileged code just because you can't test
the whole machine state after every tested instruction. Normally the bogus
privileged state of the machine will quickly expire (on the next interrupt)
and will cause no permanent state change even in those few cases where a
magic division occurs naturally.