Katherine Cox-Buday writes: > Tobias Geerinckx-Rice 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 :) My reply is long, so I'll summarize my thoughts first: - Some affected systems can be fixed without microcode updates. - I think Guix should send a message to Guix and GuixSD users explaining the problem, and explaining how to remain secure without sacrificing their freedom. - My guess is that today, microcode is really just software, so FSDG-compliant distros like GuixSD probably can't encourage users to perform a non-free microcode update. - I am curious to know if FSF currently considers microcode to be software, and I am curious to know who (if anybody) is working on making processors that would support "free microcode". Here's my full reply: Not everybody will require a microcode update. Some processors are not affected by Spectre or Meltdown at all [1], so if you're using one of those, you don't have to do anything. However, most people will probably not be so lucky, so it might be best to just assume you're affected unless you know with certainty that you're not. Even if a processor is affected, Meltdown ("rogue data cache load", CVE-2017-5754) can be mitigated in software by using KPTI (as mentioned earlier in this thread) [2], and Intel has suggested that both variant 1 of Spectre ("bounds check bypass", CVE-2017-5753) and variant 2 of Spectre ("branch target injection", CVE-2017-5715) can be mitigated for at least some Intel processors via software without a microcode update [3]. So there may very well be some systems that are vulnerable to Meltdown and both variants of Spectre, which can be protected without a microcode update. That's good news for owners of such systems, and it will be especially interesting to see if both variants of Spectre can actually be mitigated without microcode updates (i.e., entirely in software) on affected RYF-certified [4] systems. However, it's difficult to tell if you're affected or not. To really know for sure, you have to know what processor(s) you have, and you have to cross reference that information with information provided by your vendor. In some cases, this is very difficult (maybe impossible?) to determine. For example, last I heard, Qualcomm said some of their processors were vulnerable, but they declined to publicly specify which processors are vulnerable to which vulnerabilities [5]. In addition, even if you know that you're affected, it's difficult to tell what the right fix is for your particular situation. For example, even though Intel suggested that variant 1 of Spectre can be mitigated without a microcode update, ARM has said that some of their affected processors will require a microcode update to implement their recommended mitigation against this same variant [6]. I presume (perhaps naively?) that these sorts of details will be handled upstream. For example, in the current release of the Linux kernel, KPTI is enabled for all x86 CPUs, but in the near future, it looks like the Linux kernel will disable KPTI for AMD processors because they are not vulnerable to Meltdown [7]. Firefox has implemented fixes, too. As mentioned earlier in the thread, Guix has these fixes thanks to Mark's commendable efforts. I haven't looked into GCC or other software, but I presume that they will take similar steps to implement security measures in those cases where it is necessary (e.g., the retpoline technique) . In this way, mitigations that can be made using free software should trickle down to freedom-respecting distros like GuixSD over time. Therefore, I think the best things that GuixSD can communicate to its users are the following: - Briefly summarize the problem. - Continue to apply updates as Guix makes them available. - Continue to exercise other security best practices. For example, disable JavaScript in IceCat or use an extension like NoScript, and in general don't run software you don't trust. - Some kind of messaging that explains, without advocating for non-free software, what options are available to a user if she finds herself in the unfortunate position of using Guix/GuixSD on a system that currently requires a non-free microcode update to fix. The last point is obviously the most interesting. What options are available in that case? Judging by what has been published on the GNU Project and FSF websites, it looks like the FSF has historically considered things like firmware and microcode to be outside the scope of scrutiny because they were not designed to be updated, which effectively made them equivalent to hardware. According to the FSF, a trend of updating firmware began in the 1990s which led us to where we are today: firmware is frequently updated, and now the FSF's position seems to be that firmware should be free, too. They say: "As the unethical practice of installing another BIOS executable becomes common, the version delivered inside the computer starts to raise an ethical problem issue as well." [8] At what point does a microcode update start to resemble just another software update (like firmware updates have become)? I suspect that point is very close at hand, if it has not already arrived. In his essay on how to apply the free software criteria, Stallman writes [9]: "A computer can have modifiable preinstalled firmware and microcode at lower levels. It can also have code in true read-only memory. We decided to ignore these programs in our certification criteria today, because otherwise no computer could comply, and because firmware that is not normally changed is ethically equivalent to circuits. So our certification criteria cover only the code that runs on the computer's main processor and is not in true read-only memory. When and as free software becomes possible for other levels of processing, we will require free software at those levels too." The last sentence is telling. It sounds to me like he's arguing that once it becomes as easy to update your microcode as it is to update any other software on your computer, that microcode qualifies as software, so we should require it (the microcode) to be free software. However, he also said that the "we decided to ignore these programs [modifiable preinstalled firmware and microcode] in our certification criteria today, because otherwise no computer could comply". Does this mean that microcode is still outside the scope of free software today, and that it would be OK for Guix to advocate installing a non-free microcode update? Personally, based on what I currently know, I suspect that no FSDG-compliant distribution, like GuixSD, can promote a non-free microcode update, because microcode that can be easily updated is really just software. So what can a free software user do, then, if their system is affected and cannot be fixed without a non-free microcode update? There are at least a few options. Here are some that I can think of: - Get a new freedom-respecting system that is not vulnerable. - Armed with the knowledge that your processor is vulnerable, continue to use the machine, exercise caution in how you use it, continue to install updates, and hope that it will become possible in the future to fix the issue without a non-free microcode update. - Contribute to the development of freedom-respecting systems in which even the microcode can be updated in freedom, so that in the future this won't be as big of an issue. I can't think of any other freedom-respecting options. Does anyone have any other ideas? Even if it's possible to get a replacement system today which is not vulnerable (or which can be fixed without a non-free microcode update), the Spectre paper makes it seem likely that similar side-channel attacks via different micro-architectural covert channels are still waiting to be discovered in the future. Getting a new system every time one of these kinds of vulnerabilities is discovered may not be a practical long-term solution. Is any work being done today to create processors that can be programmed with "free microcode"? How does this relate to FPGAs? Since we know that fixing "hardware" problems like Spectre and Meltdown can require microcode updates, and since microcode is really just software at this point, it seems like the free software community ought to have processors that support "free microcode". If we had that, then we would not have to choose between our freedom and our security whenever a hardware vulnerability like Spectre or Meltdown occurs. Footnotes: [1] See for example: https://developer.arm.com/support/security-update [2] https://arxiv.org/abs/1801.01207 [3] https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf [4] https://www.fsf.org/ryf [5] https://www.theregister.co.uk/2018/01/06/qualcomm_processor_security_vulnerabilities/ [6] https://developer.arm.com/-/media/Files/pdf/Cache_Speculation_Side-channels.pdf?revision=966364ce-10aa-4580-8431-7e4ed42fb90b&la=en [7] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI [8] https://www.fsf.org/campaigns/free-bios.html [9] https://www.gnu.org/philosophy/applying-free-sw-criteria.html -- Chris