xdrudis at tinet.cat
Sat Apr 6 23:51:06 CEST 2013
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)
> 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
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.
More information about the coreboot