From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Meltdown / Spectre Date: Tue, 09 Jan 2018 18:10:02 -0500 Message-ID: <87vagad3xx.fsf@netris.org> References: <874lnzcedp.fsf@gmail.com> <20180106174358.GA28436@jasmine.lan> <87lghapeu5.fsf@gmail.com> <87incc6z9o.fsf@gmail.com> <87fu7g436e.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZ32Q-0005eH-Rc for guix-devel@gnu.org; Tue, 09 Jan 2018 18:10:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZ32O-00040F-5L for guix-devel@gnu.org; Tue, 09 Jan 2018 18:10:34 -0500 Received: from world.peace.net ([50.252.239.5]:32810) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eZ32N-0003zr-W0 for guix-devel@gnu.org; Tue, 09 Jan 2018 18:10:32 -0500 In-Reply-To: <87fu7g436e.fsf@fastmail.com> (Marius Bakke's message of "Mon, 08 Jan 2018 19:26:49 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke Cc: development@libreboot.org, guix-devel@gnu.org Marius Bakke writes: > Katherine Cox-Buday writes: > >> Chris Marusich writes: >> >>> Leo Famulari writes: >> >>> I wonder: how easy will it be to install those firmware/microcode >>> updates if you are using GuixSD? In particular, I'm curious about the >>> case of the Lenovo x200 with libreboot, since that's what I use >>> personally. >> >> I am also interested -- more from a philisophical perspective -- how >> GuixSD and GNU squares with these kinds of security updates. > > In my opinion, CPU microcode falls under "non-functional data", as > expressly permitted by the GNU FSDG. I strongly disagree. CPU microcode is absolutely functional data. It determines how the CPU functions. > It is not required for the processor to function, it is merely *a > posteriori* data that the CPU can use to fix erratic behaviour. Microcode *is* required for the processor to function. Upgrading it is optional, because the CPU contains a copy of the microcode in its ROM, but that doesn't change the fact that the microcode is required. By the same argument that you presented here, any proprietary software (e.g. a BIOS) would be considered optional and therefore non-functional data as long as an older copy of that software is included in the hardware of the machine. Mark