From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Meltdown / Spectre Date: Mon, 15 Jan 2018 09:07:45 +0100 Message-ID: <20180115080745.GA12963@thebird.nl> References: <874lnzcedp.fsf@gmail.com> <20180106174358.GA28436@jasmine.lan> <87lghapeu5.fsf@gmail.com> <87incc6z9o.fsf@gmail.com> <87fu7g436e.fsf@fastmail.com> <87vagad3xx.fsf@netris.org> <87tvvukqct.fsf@gmail.com> <87efmy9bml.fsf@hyperbola.info> <4b496567-2d50-6973-0eda-7c18946dac1b@platen-software.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eazrI-0000NC-0R for guix-devel@gnu.org; Mon, 15 Jan 2018 03:11:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eazrE-00086e-Qp for guix-devel@gnu.org; Mon, 15 Jan 2018 03:11:07 -0500 Received: from mail.thebird.nl ([95.154.246.10]:32917) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eazrE-00080P-KZ for guix-devel@gnu.org; Mon, 15 Jan 2018 03:11:04 -0500 Content-Disposition: inline In-Reply-To: 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: =?iso-8859-1?Q?G=E1bor?= Boskovits Cc: Guix-devel On Wed, Jan 10, 2018 at 03:04:44PM +0100, G=E1bor Boskovits wrote: > I don't believe that making a microcode update available makes > the situation worse. An earlier version is a non-free component > of the system anyway. I believe, that it might well worth to > provide the possibility to update it. I think it would be > beneficial, if we got a singned blob for that, because you > implicitly trust for example intel by buying their cpu, so a blob > signed by them could also be trusted. The second thing that > comes to my mind is to have a free tool to perform the microcode > update, so that we can inspect, that nothing else on the system > gets modified. I'm not very much into the microcode update > stuff, but I think, that given the two assumptions I mentioned, > it would be safe to provide these updates without compromising > freedom and security more than what the current situation is. I agree with you. The fact that we run untrusted hardware hardly gets improved if we can't fix it ;). GNU Guix, however, by virtue of being a GNU project is hampered by its free software credentials. We have to do what people expect from free software. The only way around this is to provide tooling outside GNU Guix. Fortunately that is not too hard since microcode is independent of the rest of the tooling. We could create a channel for this, something to discuss at FOSDEM. Channels provide a workaround for purely free software - one reason some of us are reluctant to introduce them. You can see microcode patches coming for other hardware too. Pj. --=20