From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Meltdown / Spectre Date: Wed, 10 Jan 2018 15:04:44 +0100 Message-ID: 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: multipart/alternative; boundary="94eb2c05921a71274205626c83f8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZGzm-00023R-Sl for guix-devel@gnu.org; Wed, 10 Jan 2018 09:04:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZGzl-00014c-Ua for guix-devel@gnu.org; Wed, 10 Jan 2018 09:04:46 -0500 Received: from mail-io0-x234.google.com ([2607:f8b0:4001:c06::234]:37749) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eZGzl-00014O-Nq for guix-devel@gnu.org; Wed, 10 Jan 2018 09:04:45 -0500 Received: by mail-io0-x234.google.com with SMTP id n14so22518753iob.4 for ; Wed, 10 Jan 2018 06:04:45 -0800 (PST) In-Reply-To: <4b496567-2d50-6973-0eda-7c18946dac1b@platen-software.de> 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: Guix-devel --94eb2c05921a71274205626c83f8 Content-Type: text/plain; charset="UTF-8" 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. --94eb2c05921a71274205626c83f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 anyw= ay.
I believe, that it might well worth to = provide the possibility to update it.

<= /div>
I think it would be beneficial, if we got a= singned blob for that,
because you implici= tly 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 s= ystem 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 f= reedom
and security more than what the curr= ent situation is.
--94eb2c05921a71274205626c83f8--