155 karma · joined June 26, 2010
-A ucode hack would be the ULTIMATE backdoor
-A ucode hack could damage or destroy (melt) the part. Think of things like thermal diode trim values, voltage, etc.
Intel had a billion-dollar lesson with recalls in the past, and the learning wasn't lost.
Ucode is updated every time you reset, and on each CPU. At the fab, the release ucode is burned into the design. But rarely does this last through the lifetime of a stepping. In fact, one of the main reasons why BIOS/EFI exists is to update microcode, and this is usually on one of the first things it does.
From the Intel SDM, Vol III, 9.11.6.1 "The effects of a loaded update are cleared from the processor upon a hard reset. Therefore, each time a hard reset is asserted during the BIOS POST, the update must be reloaded on all processors that observed the reset. The effects of a loaded update are, however, maintained across a processor INIT. There are no side effects caused by loading an update into a processor multiple times."
EDIT: I realize you were talking about it being a daily occurrence, and few of us reboot daily. But still, OEMs and most customers don't want a long boot time. Also note that in certain power states (deep sleep), the CPU is off, and waking up your laptop actually will cause a ucode load.
At UT, I spent 2 years programming both Haskell and C++, and then 2 years with very little programming. We focused instead on theorem proving and linguistics. This has a lot to do with Dijkstra's legacy in the department.
Implementation, industry, and start-ups are thought as an exercise left for the reader, and not part of curriculum. Throughout my career, I've always felt proud about this.