1996-04-30 - Re: trusting the processor chip

Header Data

From: frantz@netcom.com (Bill Frantz)
To: cypherpunks@toad.com
Message Hash: cd2bcd3adbc9bb54b92723ef720c302097d4d519e6b5207a8807027ef12e9e6d
Message ID: <199604292122.OAA15639@netcom9.netcom.com>
Reply To: N/A
UTC Datetime: 1996-04-30 06:20:58 UTC
Raw Date: Tue, 30 Apr 1996 14:20:58 +0800

Raw message

From: frantz@netcom.com (Bill Frantz)
Date: Tue, 30 Apr 1996 14:20:58 +0800
To: cypherpunks@toad.com
Subject: Re: trusting the processor chip
Message-ID: <199604292122.OAA15639@netcom9.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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







Thread