On Mon, Aug 27, 2012 at 02:34:53PM +1000, Chris Samuel wrote:
On 26/08/12 10:04, Ben Finney wrote:
The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob.
Do Intel CPUs count as that with the microcode driver in the kernel which lets a user space app update their firmware?
Some useful background:
Interesting to note "Microcode updates via software are not persistent. In other words, one needs to apply them at each boot which is why it is placed in the MODULES array." So if there was some important CPU bug fixed in firmware update but no BIOS update to distribute it (eg. say the CPU was running hotter than necessary and the life expectancy was drastically cut short as a result), you would be forced into loading the firmware for your CPU each time you boot, in much the same way people with AMD graphics cards need to load firmware at boot. I realise it's not exactly the same thing (because unlike the AMD case it wasn't expected to be required), but it's very close. Even Think Penguin would be unable to save you from such a scenario! :) This makes it appear very likely IMO that the BIOS is generally responsible for loading microcode into the CPU upon each boot, instead of the kernel. Interesting. -Adam