Re: trusting the processor chip

[frantz@netcom.com (Bill Frantz)]

At 10:13 AM 4/27/96 -0800, Norman Hardy wrote:
>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.

There are some limits to the extent of this kind of problem.  If the
hardware/OS you are using provides a completely disjoint memory map based
on the privileged mode state, it may be hard to exploit the ability to
switch to privileged mode.  With maps which allow access to the user's
address space while in privileged mode (e.g. Solaris), it may be possible
to just keep running, and so complete a successful attack.

On the other hand, with most systems I have seen, setting yourself into
privileged state will persist thru the next interrupt.  The system Norm and
I worked on would detect it later.  (It checked every 5 minutes or so.) 
The IBM operating systems I have used would not detect, or correct this
change.

The ray  of hope in this area is that there are so many other easier
attacks on modern systems.  People will have a tendency to use them first.

Regards - Bill


------------------------------------------------------------------------
Bill Frantz       | The CDA means  | Periwinkle  --  Computer Consulting
(408)356-8506     | lost jobs and  | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA