Re: Meltdown / Spectre

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 12152 bytes --]

2018-01-16 4:58 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
> > Tobias Geerinckx-Rice <me@tobias.gr> 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.
>
> What I've found out basically boils down this:
- we do have rtl level descriptions that practically allows this
- we don't have any free toolchain that is able to synthetize these for a
powerful enough FPGA
- we don't have any free toolchain that is able to synthetize an asic from
the rtl
- we have this: https://github.com/sifive/freedom
<https://github.com/sifive/freedom>, this is rtl level
- we have this: http://www.clifford.at/icestorm/
<http://www.clifford.at/icestorm/>, this is a project where a small FPGA
was reverse engineered
- we also have this: https://www.gnu.org/software/electric/

So, the final point is that though we have rtl level descriptions of
powerful enough designs,
(and at that level you have the microde if any) we have no way
to check, that an implemented ASIC or and FPGA and a bitstream for the FPGA
really do what is in the
design document. I don't see that full open sourcing can be done any other
ways than providing the hardware
manifacturing documentation. As long as we don't have access to that, we
will always have to trust that a
circuit adheres to the specifications. We could eliminate attack vectors on
one level, but there is the next level,
and a timing based attack is still possible all the way down to the bare
silicon.

What can be currently reasonably done:
- create synthesis tools to lower the rtl description to the gate level
- create a general purpose free cell library - this will not be optimized,
but gives a design tool anyway - for optimizations you have to know
something about the hardware

What seems to be out of reach:
- create an optimizing placer for the gates
- document the bitstreams of FPGAs, in such a way, that a reasonable
bitstream generator can easily adhere to the ever changing structure
- get the custom FPGA tiles the documentation, that is at least rtl level


> 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_Speculatio
> n_Side-channels.pdf?revision=966364ce-10aa-4580-8431-7e4ed42fb90b&la=en
>
> [7]  https://www.phoronix.com/scan.php?page=news_item&px=Linux-Ti
> p-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
>

[-- Attachment #2: Type: text/html, Size: 15366 bytes --]