From: nobody@REPLAY.COM (Anonymous)
Date: Sat, 26 Jul 1997 11:42:38 +0800
To: cypherpunks@toad.com
Subject: Pentium Microcode Encryption (was Re: Another vulnerability)
Message-ID: <199707260330.FAA28597@basement.replay.com>
MIME-Version: 1.0
Content-Type: text/plain



> BIOS Update is a hidden feature that can fix bugs in Pentium Pro and
> Pentium II CPUs by patching the microcode inside the microprocessor.
> When the processor boots up, the BIOS loads the patches, which are
> contained in a 2,048-byte-long BIOS Update data block that is supplied
> by Intel.
> "The problem is, the BIOS cannot verify whether the BIOS Update data
> block contains real microcode or not," claimed one BIOS expert, who
> requested anonymity. "As long as the header and the checksum are okay,
> the BIOS will load that microcode into the microprocessor. Some hacker
> could actually wipe out microcode in the CPU. There is nothing that can
> prevent this."

The processor doesn't actually burn in the patch to on on-board EPROM,
does it?  (If it did, then the BIOS wouldn't need to load it on boot-up.)
So you can't actually wipe out microcode in the CPU.

> Intel doesn't see such a scenario as a realistic threat, pointing to
> the fact that the BIOS Update data block is encrypted. "We've spent
> quite a lot of time thinking about such scenarios to make sure we had
> sufficient mechanisms in place so you couldn't introduce your own
> flavor of BIOS Update into the processor," said Ajay Malhortra, a
> technical marketing manager based here at Intel's microprocessor
> group. "Not only is the data block containing the microcode patch
> encrypted, but once the processor examines the header of the BIOS
> update, there are two levels of encryption in the processor that must
> occur before it will successfully load the update."

I can't imagine them wasting precious die space to implement a multiple
round, fully cryptanalysis-proof encryption scheme, especially
considering that the microcode-update curcuitry takes up quite a bit of
space already.  It seems more likely that they would use a combination
of a few logic gates and some permutations, which wouldn't take up much
space.  (Unless, of course, they implemented the microcode-updater as
microcode software itself, which would be a really stupid thing to do -
How could the program run while overwriting itself?)

Furthermore, they mentioned "there are two levels of encryption in the
processor"  That is really bad design from a cryptanalysis point of view.
Once the outer layer has been stripped off and you find a valid header,
you can then attack the next layer by itself.  (assume a valid header
decryption could be determined by it having a low entropy in the
data-compression sense.)

That leaves the checksum question.  CRC is widely used, so they probably
had a crc design on file and could have just stuck it in.  But there is
no other use for crc calculation in the cpu, and an arithmetic checksum,
or ever XOR would be simpler.  Hmm...  (Of course you could always try to
do it like Matt Blaze did with clipper. :)

> "Yes, it is used," said an engineer at one vendor. "I personally know
> of five different things in the Pentium Pro related to multiprocessing,
> system management interrupt and other areas."

That sounds like it could be very useful.  A context-switch on a pentium
takes over a hundred clock cycles while the processor dumps all its
registers.  The problem is that on a modern 32-bit OS many of those
registers, such as the 16-bit segment registers, are not used.  If you
could change the microcode so that it would temporarily ignore those
registers it would give you faster task-switching and better performance.
I think a lot of Linux users would be interested in something like that.

Anyone know where I could find some of these 2048-byte update blocks?
It might be interesting to run some statistical analysis on it... :)