Hi,
In src/cpu/intel/model_6fx/model_6fx_init.c there is: /* * This file is part of the coreboot project. * * Copyright (C) 2007-2009 coresystems GmbH * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; version 2 of * the License. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, * MA 02110-1301 USA */ [...] static const uint32_t microcode_updates[] = { #include "microcode-1624-m206e839.h" #include "microcode-1729-m206ec54.h" #include "microcode-1869-m806ec59.h" /* Dummy terminator */ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, }; [...] static void model_6ex_init(device_t cpu) { [...] /* Update the microcode */ intel_update_microcode(microcode_updates); [...] } [...]
That raises some questions:
The first one is the following: Is the inclusion of the microcode in GPLv2 source code compatible with the GPLv2? Because the microcode-1624-m206e839.h has: //+++ // Copyright (c) <1995-2010>, Intel Corporation. // All rights reserved. // // Redistribution. Redistribution and use in binary form, without modification, are // permitted provided that the following conditions are met: // .Redistributions must reproduce the above copyright notice and the following // disclaimer in the documentation and/or other materials provided with the // distribution. // .Neither the name of Intel Corporation nor the names of its suppliers may be used // to endorse or promote products derived from this software without specific prior // written permission. // .No reverse engineering, decompilation, or disassembly of this software is // permitted. // ."Binary form" includes any format commonly used for electronic conveyance // which is a reversible, bit-exact translation of binary representation to ASCII or // ISO text, for example, "uuencode." // // DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT // HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED // WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED // WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR // PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER // OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, // SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT // NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; // LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER // CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF // ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. // //--- /* Tue Feb 9 12:54:50 CST 2010 */ /* 1624-m206e839.inc */
which prevents: * modification * reverse engineering, decompilation, disassembly
The second question is about Kconfig: In the CPU section in make menuconfig there is a choice about microcode: Include CPU microcode in CBFS (Do not include microcode updates) --->
That is misleading, because according to the code that is before, it does include the microcode,not even in CBFS(but included in the code like before), and it also updates it.
The third question is the following: Which CPU(or laptop, or mainboard+CPU) still work without the microcode and which doesn't.
Denis.
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