On Sat, Apr 06, 2013 at 02:47:06PM +0200, Denis 'GNUtoo' Carikli wrote:
Is the inclusion of the microcode in GPLv2 source code compatible with the GPLv2?
I think the correct thing legally would be to load the microcode from a file (or let the CPU work with the factory microcode and not update it). But IANAL and it all may depend on what is considered a derived work on each jurisdiction. In the end there's going to be a .rom file that will include the GPL code and the propietary microcode, but that rom file might not be regarded as a derived work of the GPL code but an aggregation of differently licensed works, at least if it is separated in a file in CBFS and not #included .
Some years ago I think I suggested this potential risk but since I (or anyone) didn't write the code to load it from outside coreboot, it didn't go any further. I don't know how it is now. I was trying to have my CPU (AMD, not Intel) boot without updating its microcode. I did get further without updating microcode that updating it, but the furthest I got was to load and start booting linux-libre. The kernel wasn't able to mount the root filesystem and I run out of time trying to fix it.
The thread is here (about AMD, mind you) http://marc.info/?l=linuxbios&m=129814821921378&w=4 http://marc.info/?l=linuxbios&m=129880053021153&w=4
The third question is the following: Which CPU(or laptop, or mainboard+CPU) still work without the microcode and which doesn't.
I don't know. I'm told some don't work well without microcode updates, mine seems to work better without microcode updates, but I can't confirm it because I didn't get the whole system to work. It possibly depends on the available microcode. It's not going to be good to update a CPU with microcode for another model. I guess the microcode that comes from factory, without microcode updates, should work. It is designed to work. But then there may be bugs, and that's why they issue new versions of microcode which can reach or not coreboot. The hardware design, the microcode design and the bugs are possibly all secrets, so there's no way to know if applying the update is really needed in some scenario. So people trust the only party with the information (the CPU company) and apply the updates just in case.
The kernel may also try to update microcode if you don't tell it otherwise.
Just in advance of what you could find next:
I was also told that some versions of Intel CPUs can't even access RAM if they don't boot some propietary signed code (the boot CPU inside the CPU checks the signature before running it). This is no microcode, but it is propietary (and unchangeable even if it could be reverse engineered, unless you find some exploitable vulnerability). If my memory serves this code is not in the coreboot repository, but must be included in the rom image to boot those intel CPUs. That suggests to me that it is an external file and does not fall under GPL, so it seems it is both legal and maybe a clue if someone wants to extract microcode so that coreboot loads it from CBFS, but I haven't checked how it is done and IANAL.
http://www.coreboot.org/pipermail/coreboot/2012-April/069598.html