Re: Meltdown / Spectre

[Chris Marusich]

Katherine Cox-Buday <address@hidden> 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 :)

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

signature.asc
Description: PGP signature