guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meltdown / Spectre


From: Kei Kebreau
Subject: Re: Meltdown / Spectre
Date: Wed, 10 Jan 2018 13:41:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Christopher Lemmer Webber <address@hidden> writes:

> Katherine Cox-Buday writes:
>
>> Tobias Geerinckx-Rice <address@hidden> writes:
>>
>>
>>> I think the real and thornier question for GuixSD
>>> is: if the recent CPU vulnerabilities require a
>>> microcode update to fully mitigate, then how do we
>>> square not recommending proprietary globs like
>>> this in official channels with giving users all
>>> knowledge required to decide for themselves?
>>
>> Yes, this exactly.
>>
>> It's a unique (hm, is it?) situation pitting the ideals of copyleft
>> against the welfare of users. If an opaque microcode is required to
>> successfully mitigate these bugs, what is the moral stance to take?
>>
>> I don't have an answer and that's why I'm asking here :)
>
> It seems to me that this is one of those "you need to upgrade some
> lowest level firmware which you already didn't have access to in order
> to keep your system secure"... I dunno if GuixSD should ship something,
> but I wouldn't blame anyone updating their microcode for something this
> critical.
>

My interpretation of the GNU FSDG leads me to believe that GuixSD
shouldn't ship anything. Because the opaque microcode update in question
is proprietary and necessarily runs on the CPU, we cannot and should not
recommend it. See how Libreboot addresses this issue:
https://libreboot.org/faq.html#microcode.

> That said, if the microcode were free in the first place, this would
> probably be a lot easier to deal with?

Yes, this would not be a problem. The real problem is with the
proprietary and thus harmful nature of Intel's microcode. Even if the
FSDG allowed for nonfree firmware in this case, there is no way to
verify with certainty that the microcode update does what it claims (and
/only/ what it claims, for that matter).

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]