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... :)