What do Meltdown and Spectre mean for libreboot x200 user?

What do Meltdown and Spectre mean for libreboot x200 user?

[Alex Vong]

Hello,

I hope this is on topic. Recently, 2 critical vulnerabilities (see
https://meltdownattack.com/) affecting virtually all intel cpus are
discovered. I am running libreboot x200 (see
https://www.fsf.org/ryf). What should I do right now to patch my laptop?

Cheers,
Alex

Re: What do Meltdown and Spectre mean for libreboot x200 user?

[Mark H Weaver]

Hi Alex,

Alex Vong <alexvong1995@gmail.com> writes:
> I hope this is on topic. Recently, 2 critical vulnerabilities (see
> https://meltdownattack.com/) affecting virtually all intel cpus are
> discovered. I am running libreboot x200 (see
> https://www.fsf.org/ryf). What should I do right now to patch my laptop?

I haven't yet had time to properly study this, but so far I'd strongly
recommend updating to linux-libre-4.14.12, which contains an important
mitigation called kernel page-table isolation (KPTI).
linux-libre-4.9.75 also contains backported mitigations, but I'm not
sure if they're as comprehensive.

Alan Cox also says that Javascript can be used to remotely exploit these
vulnerabilities, so you should use the NoScript web browser extension if
you're not already doing so.  Enable Javascript only when you must.  He
wrote:

  What you do need to care about _big_ _time_ is javascript because the
  exploit can be remotely used by javascript on web pages to steal stuff
  from your system memory. Mozilla and Chrome both have pending
  updates. and some recommendations about protection. Also consider
  things like Adblockers and extensions like noscript that can stop a
  lot of junk running in the first place. Do that ASAP.

  https://plus.google.com/+AlanCoxLinux/posts/Z6inLSq4iqH

We (GNU Guix developers) should also start investigating how to deploy
the "Retpoline" mitigation technique, which apparently involves patching
our linker and recompiling our entire system with it, but it will take
some time to do that.

  https://support.google.com/faqs/answer/7625886

      Mark

Meltdown / Spectre

[Leo Famulari]

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

On Sat, Jan 06, 2018 at 09:20:50PM +0800, Alex Vong wrote:
> I hope this is on topic. Recently, 2 critical vulnerabilities (see
> https://meltdownattack.com/) affecting virtually all intel cpus are
> discovered. I am running libreboot x200 (see
> https://www.fsf.org/ryf).

> What should I do right now to patch my laptop?

### What to do now ###

Assuming you are running GuixSD, do this as root to update your kernel:

# guix pull && guix system reconfigure path/to/config.scm && reboot

If you are running another distro, update the kernel in the normal way.
Take any updates to your web browser packages on that distro.

### Who is affected? ###

I'd like to clarify that these issues are not limited to Intel CPUs.
They affect any CPU that executes out-of-order, which is almost all of
them for several years now.

Some of the very slow and simple ARM CPUs execute in-order and are not
affected.

Please consult the chip makers for more detail.

### Guix status ###

The CPU makers are issuing microcode updates as a hardware-level
mitigation, but I don't think we'll be providing those in Guix.

The first mitigations available in Guix are in the kernel.

We got the initial mitigation for Meltdown, Linux page table isolation
(KPTI), in linux-libre 4.14.11 on January 3:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=10db5e98ed7036e873060501462345c37fe2855c

Last night we got KPTI for the 4.4 and 4.9 kernel series, in 4.4.110 and
4.9.75, respectively. At the same time, we made 4.14.12 available, which
has some changes to KPTI in that kernel:

4.4.110:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=630437d94eeeae52586ab2362aa4273e0424cdf3
4.9.75:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f2462bc3662733801d7df7c532c1d8b0c67b3c18
4.14.12:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=af3f7f22f43fbbdca9bdc00afc476dd2ac86c017

The primary Linux stable kernel maintainer, Greg Kroah-Hartman, has more
details about these problems, what Linux is doing about them, and what
you can expect from them next:

http://kroah.com/log/blog/2018/01/06/meltdown-status/

The Spectre bugs have to be fixed per-application for now. As far as I
know, we haven't made any related changes to packages besides
linux-libre.

Mozilla has released an update that is supposed to mitigate the
vulnerability but I don't if they'll be porting it back to the extended
support release that Icecat is based on.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> The Spectre bugs have to be fixed per-application for now. As far as I
> know, we haven't made any related changes to packages besides
> linux-libre.
>
> Mozilla has released an update that is supposed to mitigate the
> vulnerability but I don't if they'll be porting it back to the extended
> support release that Icecat is based on.

I just backported the Spectre mitigation from Firefox 57.0.4 to IceCat,
and pushed it to master here:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c23243fccd4f73430ca06a862acd33c020c8ed17

I recommend that you upgrade your IceCat packages, and furthermore that
you install NoScript and avoid using Javascript except when needed.

      Mark

Re: Meltdown / Spectre

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> The Spectre bugs have to be fixed per-application for now. As far as I
>> know, we haven't made any related changes to packages besides
>> linux-libre.
>>
>> Mozilla has released an update that is supposed to mitigate the
>> vulnerability but I don't if they'll be porting it back to the extended
>> support release that Icecat is based on.
>
> I just backported the Spectre mitigation from Firefox 57.0.4 to IceCat,
> and pushed it to master here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c23243fccd4f73430ca06a862acd33c020c8ed17

I just followed this up with a Spectre mitigation for WebKitGTK+
backported from upstream WebKit:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f

Note that WebKitGTK+ had already reduced the resolution of
performance.now() to 100 microseconds over a year ago:

  https://bugs.webkit.org/show_bug.cgi?id=165503

       Mark

Re: Meltdown / Spectre

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> I just followed this up with a Spectre mitigation for WebKitGTK+
> backported from upstream WebKit:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f

FYI, adding a patch to 'webkitgtk' seems to have greatly exacerbated an
existing race condition in webkitgtk's build system, presumably due to
the zeroing of time stamps in the repacked tarball.  I believe that
*any* patch would have had this effect.  I filed the following bug to
track this issue:

  https://bugs.gnu.org/30015

      Mark

Re: Meltdown / Spectre

[Alex Vong]

Mark H Weaver <mhw@netris.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> I just followed this up with a Spectre mitigation for WebKitGTK+
>> backported from upstream WebKit:
>>
>>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f
>
> FYI, adding a patch to 'webkitgtk' seems to have greatly exacerbated an
> existing race condition in webkitgtk's build system, presumably due to
> the zeroing of time stamps in the repacked tarball.  I believe that
> *any* patch would have had this effect.  I filed the following bug to
> track this issue:
>
>   https://bugs.gnu.org/30015
>
>       Mark

Thanks for all the help and quick fixes.

I have an idea. Should we add a news entry to Guix blog[0] summarizing
all the above? For example, we can advice users to install noscript and
turn off javascript by default and only enable it on trusted site when
necessary.

About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
core-updates.  So I tried to apply the patches apply the patches to
5.5.0. There are totally 17 commits/patches. The first 3 patch can be
modified to work while the 4th patch cannot be easily modified to work
because the function ``ix86_nopic_noplt_attribute_p'' is not present on
5.5.0. Perhaps discarding the hunk would be fine, but we need to be
careful about it (maybe running tests make sure the fix really works).

Do you think we should modify the patch to make it work on GCC 5 or
update core-updates to GCC 7 instead?

[0]: https://www.gnu.org/software/guix/blog/
[1]: http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/retpoline

Re: Meltdown / Spectre

[Leo Famulari]

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

On Wed, Jan 10, 2018 at 05:39:59AM +0800, Alex Vong wrote:
> I have an idea. Should we add a news entry to Guix blog[0] summarizing
> all the above? For example, we can advice users to install noscript and
> turn off javascript by default and only enable it on trusted site when
> necessary.

I think it's a good idea to publish an advisory of some sort but I don't
know if I'll have time in the next few days to write it.

> About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
> is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
> core-updates.  So I tried to apply the patches apply the patches to
> 5.5.0. There are totally 17 commits/patches. The first 3 patch can be
> modified to work while the 4th patch cannot be easily modified to work
> because the function ``ix86_nopic_noplt_attribute_p'' is not present on
> 5.5.0. Perhaps discarding the hunk would be fine, but we need to be
> careful about it (maybe running tests make sure the fix really works).
> 
> Do you think we should modify the patch to make it work on GCC 5 or
> update core-updates to GCC 7 instead?

So far I haven't had time to read about Retpoline, how it works, and the
degree to which other mitigations work without it. So the following
opinion is from a place of ignorance. I'm very interested to hear what
everyone else thinks about your suggestion.

Having said that, my opinion is that it's too late in this core-updates
cycle to change the default GCC version, especially two major versions,
from 5 to 7.

My impression is that we are relatively close to finishing this cycle.
Changing the default GCC would surely cause lots of new build failures
requiring fixes to affected packages.

There are probably many unpublicized / undiscovered security fixes in
many of the updates on core-updates. It's valuable to deploy those as
quickly as possible. Is it more valuable than waiting until we can build
the packages with GCC 7? I don't know.

Something we can do very easily, even on the master branch, is to build
specific packages with GCC 7, assuming the Retpoline technique would be
effective in that context.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Ludovic Courtès]

Hello,

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Jan 10, 2018 at 05:39:59AM +0800, Alex Vong wrote:
>> I have an idea. Should we add a news entry to Guix blog[0] summarizing
>> all the above? For example, we can advice users to install noscript and
>> turn off javascript by default and only enable it on trusted site when
>> necessary.
>
> I think it's a good idea to publish an advisory of some sort but I don't
> know if I'll have time in the next few days to write it.

It’s a good idea.  I think the message you sent at the beginning of this
thread would be a good start.  Not much more needs to be added at this
point, IMO.

>> About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
>> is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
>> core-updates.  So I tried to apply the patches apply the patches to
>> 5.5.0. There are totally 17 commits/patches. The first 3 patch can be
>> modified to work while the 4th patch cannot be easily modified to work
>> because the function ``ix86_nopic_noplt_attribute_p'' is not present on
>> 5.5.0. Perhaps discarding the hunk would be fine, but we need to be
>> careful about it (maybe running tests make sure the fix really works).
>> 
>> Do you think we should modify the patch to make it work on GCC 5 or
>> update core-updates to GCC 7 instead?
>
> So far I haven't had time to read about Retpoline, how it works, and the
> degree to which other mitigations work without it. So the following
> opinion is from a place of ignorance. I'm very interested to hear what
> everyone else thinks about your suggestion.
>
> Having said that, my opinion is that it's too late in this core-updates
> cycle to change the default GCC version, especially two major versions,
> from 5 to 7.

No doubt about it.  :-)

> Something we can do very easily, even on the master branch, is to build
> specific packages with GCC 7, assuming the Retpoline technique would be
> effective in that context.

Yes, I see Alex submitted a patch already.

Thanks,
Ludo’.

Re: Meltdown / Spectre

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Leo Famulari <leo@famulari.name> skribis:
>
>> On Wed, Jan 10, 2018 at 05:39:59AM +0800, Alex Vong wrote:
>>> About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
>>> is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
>>> core-updates.  So I tried to apply the patches apply the patches to
>>> 5.5.0. There are totally 17 commits/patches. The first 3 patch can be
>>> modified to work while the 4th patch cannot be easily modified to work
>>> because the function ``ix86_nopic_noplt_attribute_p'' is not present on
>>> 5.5.0. Perhaps discarding the hunk would be fine, but we need to be
>>> careful about it (maybe running tests make sure the fix really works).
>>> 
>>> Do you think we should modify the patch to make it work on GCC 5 or
>>> update core-updates to GCC 7 instead?
>>
>> So far I haven't had time to read about Retpoline, how it works, and the
>> degree to which other mitigations work without it. So the following
>> opinion is from a place of ignorance. I'm very interested to hear what
>> everyone else thinks about your suggestion.
>>
>> Having said that, my opinion is that it's too late in this core-updates
>> cycle to change the default GCC version, especially two major versions,
>> from 5 to 7.
>
> No doubt about it.  :-)
>
>> Something we can do very easily, even on the master branch, is to build
>> specific packages with GCC 7, assuming the Retpoline technique would be
>> effective in that context.
>
> Yes, I see Alex submitted a patch already.

There's now a GCC 7.3 release candidate that apparently contains the
necessary compiler support to allow linux-libre-4.14.14 to use the
retpoline technique internally.

  https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html

They hope to release GCC 7.3 on January 24th.  It would be good to
promptly add GCC 7.3 to Guix when its released, and to start using it to
build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.

I'd prefer to continue using our default compiler to build linux-libre
on systems where GCC 7.3 is not known to help with this issue.

       Mark

Re: Meltdown / Spectre

[Leo Famulari]

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

On Fri, Jan 19, 2018 at 05:06:25PM -0500, Mark H Weaver wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> > Leo Famulari <leo@famulari.name> skribis:
> >> Something we can do very easily, even on the master branch, is to build
> >> specific packages with GCC 7, assuming the Retpoline technique would be
> >> effective in that context.
> >
> > Yes, I see Alex submitted a patch already.
> 
> There's now a GCC 7.3 release candidate that apparently contains the
> necessary compiler support to allow linux-libre-4.14.14 to use the
> retpoline technique internally.
> 
>   https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html
> 
> They hope to release GCC 7.3 on January 24th.  It would be good to
> promptly add GCC 7.3 to Guix when its released, and to start using it to
> build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.
> 
> I'd prefer to continue using our default compiler to build linux-libre
> on systems where GCC 7.3 is not known to help with this issue.

Thanks for looking into this, Mark. Your plan sounds good to me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> On Fri, Jan 19, 2018 at 05:06:25PM -0500, Mark H Weaver wrote:
>> There's now a GCC 7.3 release candidate that apparently contains the
>> necessary compiler support to allow linux-libre-4.14.14 to use the
>> retpoline technique internally.
>> 
>>   https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html
>> 
>> They hope to release GCC 7.3 on January 24th.  It would be good to
>> promptly add GCC 7.3 to Guix when its released, and to start using it to
>> build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.
>> 
>> I'd prefer to continue using our default compiler to build linux-libre
>> on systems where GCC 7.3 is not known to help with this issue.
>
> Thanks for looking into this, Mark. Your plan sounds good to me.

FYI, in another thread, I recently posted preliminary patches to add the
GCC 7.3 release candidate as a Guix package, and to use it to build
linux-libre on x86_64 and i686 systems:

  https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html

      Mark

Re: Meltdown / Spectre

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Fri, Jan 19, 2018 at 05:06:25PM -0500, Mark H Weaver wrote:
>>> There's now a GCC 7.3 release candidate that apparently contains the
>>> necessary compiler support to allow linux-libre-4.14.14 to use the
>>> retpoline technique internally.
>>> 
>>>   https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html
>>> 
>>> They hope to release GCC 7.3 on January 24th.  It would be good to
>>> promptly add GCC 7.3 to Guix when its released, and to start using it to
>>> build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.
>>> 
>>> I'd prefer to continue using our default compiler to build linux-libre
>>> on systems where GCC 7.3 is not known to help with this issue.
>>
>> Thanks for looking into this, Mark. Your plan sounds good to me.
>
> FYI, in another thread, I recently posted preliminary patches to add the
> GCC 7.3 release candidate as a Guix package, and to use it to build
> linux-libre on x86_64 and i686 systems:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html

Today’s Jan. 24th, so hopefully we can roll in these patches today!

Thank you,
Ludo’.

Re: Meltdown / Spectre

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> FYI, in another thread, I recently posted preliminary patches to add the
>> GCC 7.3 release candidate as a Guix package, and to use it to build
>> linux-libre on x86_64 and i686 systems:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html
>
> Today’s Jan. 24th, so hopefully we can roll in these patches today!

It won't be today, but maybe tomorrow:

  https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html

      Mark

Re: Meltdown / Spectre

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> FYI, in another thread, I recently posted preliminary patches to add the
>> GCC 7.3 release candidate as a Guix package, and to use it to build
>> linux-libre on x86_64 and i686 systems:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html
>
> Today’s Jan. 24th, so hopefully we can roll in these patches today!

FYI, the GCC 7.3 update, and the patch to use it to build linux-libre,
are now on the master branch, and the new kernels have been built by
Hydra.

      Mark

Re: Meltdown / Spectre

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> FYI, in another thread, I recently posted preliminary patches to add the
>>> GCC 7.3 release candidate as a Guix package, and to use it to build
>>> linux-libre on x86_64 and i686 systems:
>>>
>>>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html
>>
>> Today’s Jan. 24th, so hopefully we can roll in these patches today!
>
> FYI, the GCC 7.3 update, and the patch to use it to build linux-libre,
> are now on the master branch, and the new kernels have been built by
> Hydra.

Excellent, thanks!  (Ignore my previous message on this topic.)

Ludo’.

Re: Meltdown / Spectre

[ng0]

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

Alex Vong transcribed 1.7K bytes:
> Mark H Weaver <mhw@netris.org> writes:
> 
> > Mark H Weaver <mhw@netris.org> writes:
> >
> >> I just followed this up with a Spectre mitigation for WebKitGTK+
> >> backported from upstream WebKit:
> >>
> >>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f
> >
> > FYI, adding a patch to 'webkitgtk' seems to have greatly exacerbated an
> > existing race condition in webkitgtk's build system, presumably due to
> > the zeroing of time stamps in the repacked tarball.  I believe that
> > *any* patch would have had this effect.  I filed the following bug to
> > track this issue:
> >
> >   https://bugs.gnu.org/30015
> >
> >       Mark
> 
> Thanks for all the help and quick fixes.
> 
> I have an idea. Should we add a news entry to Guix blog[0] summarizing
> all the above? For example, we can advice users to install noscript and
> turn off javascript by default and only enable it on trusted site when
> necessary.

Yes. If you ask yourself the question, it's already possible that someone
out there (realistic: multiple someones) doesn't follow the mailinglist
all the time and they miss it out. a summary on the website will be good imho.

> About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
> is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
> core-updates.  So I tried to apply the patches apply the patches to
> 5.5.0. There are totally 17 commits/patches. The first 3 patch can be
> modified to work while the 4th patch cannot be easily modified to work
> because the function ``ix86_nopic_noplt_attribute_p'' is not present on
> 5.5.0. Perhaps discarding the hunk would be fine, but we need to be
> careful about it (maybe running tests make sure the fix really works).
> 
> Do you think we should modify the patch to make it work on GCC 5 or
> update core-updates to GCC 7 instead?
> 
> [0]: https://www.gnu.org/software/guix/blog/
> [1]: http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/retpoline
> 
> 

-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is/a/  ::  https://ea.n0.is

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> The Spectre bugs have to be fixed per-application for now. As far as I
>>> know, we haven't made any related changes to packages besides
>>> linux-libre.
>>>
>>> Mozilla has released an update that is supposed to mitigate the
>>> vulnerability but I don't if they'll be porting it back to the extended
>>> support release that Icecat is based on.
>>
>> I just backported the Spectre mitigation from Firefox 57.0.4 to IceCat,
>> and pushed it to master here:
>>
>>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c23243fccd4f73430ca06a862acd33c020c8ed17
>
> I just followed this up with a Spectre mitigation for WebKitGTK+
> backported from upstream WebKit:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f

Thanks a lot Leo and Mark for the quick fixes and the detailed report.

Ludo’.

Re: Meltdown / Spectre

[Leo Famulari]

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

On Sun, Jan 07, 2018 at 01:38:40AM -0500, Mark H Weaver wrote:
> Mark H Weaver <mhw@netris.org> writes:
> > I just backported the Spectre mitigation from Firefox 57.0.4 to IceCat,
> > and pushed it to master here:
> >
> >   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c23243fccd4f73430ca06a862acd33c020c8ed17
> 
> I just followed this up with a Spectre mitigation for WebKitGTK+
> backported from upstream WebKit:
> 
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56804398a94bea941183ae4ed29d2a9f82069a6f

Thank you, Mark. This effort is exemplary.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Chris Marusich]

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

Leo Famulari <leo@famulari.name> writes:

> ### Guix status ###
>
> The CPU makers are issuing microcode updates as a hardware-level
> mitigation, but I don't think we'll be providing those in Guix.

It seems some (but not all) mitigations may require firmware/microcode
updates.  For details, see:

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
https://developer.arm.com/support/security-update

I wonder: how easy will it be to install those firmware/microcode
updates if you are using GuixSD?  In particular, I'm curious about the
case of the Lenovo x200 with libreboot, since that's what I use
personally.

> The first mitigations available in Guix are in the kernel.
>
> We got the initial mitigation for Meltdown, Linux page table isolation
> (KPTI), in linux-libre 4.14.11 on January 3:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=10db5e98ed7036e873060501462345c37fe2855c
>
> Last night we got KPTI for the 4.4 and 4.9 kernel series, in 4.4.110 and
> 4.9.75, respectively. At the same time, we made 4.14.12 available, which
> has some changes to KPTI in that kernel:
>
> 4.4.110:
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=630437d94eeeae52586ab2362aa4273e0424cdf3
> 4.9.75:
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f2462bc3662733801d7df7c532c1d8b0c67b3c18
> 4.14.12:
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=af3f7f22f43fbbdca9bdc00afc476dd2ac86c017

That's great!

> Mozilla has released an update that is supposed to mitigate the
> vulnerability but I don't if they'll be porting it back to the extended
> support release that Icecat is based on.

My understanding is that those changes just mitigate the known methods
for the Spectre attack via Javascript.  Surely, other ways will be
discovered and abused, until a more holistic fix for Spectre is in
place.  See also the following paper, which claims to have found
alternative ways to mount similar attacks:

https://gruss.cc/files/fantastictimers.pdf

Probably, the safest thing one can do right now is disable Javascript by
default and judiciously enable it only for websites that you trust.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Meltdown / Spectre

[Katherine Cox-Buday]

Chris Marusich <cmmarusich@gmail.com> writes:

> Leo Famulari <leo@famulari.name> writes:

> I wonder: how easy will it be to install those firmware/microcode
> updates if you are using GuixSD? In particular, I'm curious about the
> case of the Lenovo x200 with libreboot, since that's what I use
> personally.

I am also interested -- more from a philisophical perspective -- how
GuixSD and GNU squares with these kinds of security updates.

-- 
Katherine

Re: Meltdown / Spectre

[Marius Bakke]

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

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Leo Famulari <leo@famulari.name> writes:
>
>> I wonder: how easy will it be to install those firmware/microcode
>> updates if you are using GuixSD? In particular, I'm curious about the
>> case of the Lenovo x200 with libreboot, since that's what I use
>> personally.
>
> I am also interested -- more from a philisophical perspective -- how
> GuixSD and GNU squares with these kinds of security updates.

In my opinion, CPU microcode falls under "non-functional data", as
expressly permitted by the GNU FSDG.

It is not required for the processor to function, it is merely *a
posteriori* data that the CPU can use to fix erratic behaviour.

Just my 2 NOK,
Marius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Meltdown / Spectre

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 1667 bytes --]

Hej Marius,

[I see this is being CC'd to @libreboot.org. I'm answering only as a GNU
 Guix user and contributor, and assume people who live and breathe this
 stuff will find plenty of holes in my opinion. Which this is.]

Marius Bakke wrote on 08/01/18 at 19:26:
> In my opinion, CPU microcode falls under "non-functional data", as
> expressly permitted by the GNU FSDG.

I'm not sure how tongue-in-cheek this is, so I'm not sure how to
respond. I hope nobody on the Internet is wrong^Wseriously suggesting
that microcode or any other firmware isn't machine code and —
unfortunately for everyone everywhere — very (dis)functional indeed.

(Don't get me wrong: I wish it weren't so, or that there were some sort
 of commonly-agreed-upon wink-nudge fiction that it wasn't. If there is,
 then Debian isn't playing along: microcode blobs are ‘non-free’[0].)

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?

> It is not required for the processor to function, it is merely *a
> posteriori* data that the CPU can use to fix erratic behaviour.

AIUI, at least on x86 CPUs, the microcode *is* a large and/or functional
part of the processor. I suspect that's the case for most sufficiently
modern (complex) chips, but it's not my field.

Kind regards,

T G-R

[0]: https://lists.debian.org/debian-devel/2012/11/msg00109.html,
     https://packages.debian.org/search?keywords=microcode


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

Re: Meltdown / Spectre

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 379 bytes --]

I should probably have written what I thought:

Tobias Geerinckx-Rice wrote on 08/01/18 at 22:51:
> AIUI, at least on x86 CPUs, the microcode *is* a large and/or functional
> part of the processor...

...but it's initially included in ROM. Only when bugs are found in that
copy does a user-provided ‘update’ (at every boot) become needed.

Kind regards,

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

Re: Meltdown / Spectre

[Katherine Cox-Buday]

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 :)

-- 
Katherine

Re: Meltdown / Spectre

[Tobias Geerinckx-Rice]

Katherine,

Not really an answer to your question, I'm afraid. Just some thoughts I
had after hitting ‘Send’ on my previous non-answer.

Katherine Cox-Buday wrote on 09/01/18 at 21:13:
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>> [...] 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

I don't think it's unique per se, but it is of another degree entirely
than, for example, asking users to buy a €15 RYF-certified wireless card
instead of pushing proprietary firmware to the one they already have.[0]

The rationale there being that freedom is worth the price, and
(implicitly but importantly) that this price is affordable for anyone
who values their freedom and owns a computer to begin with.

I think that's reasonable.

> 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 :)

Logically, it's perfectly sound to extrapolate the above policy to CPUs
and entire systems. I'm half surprised someone hasn't done so yet: buy a
Free(er) system, and you're arguably much better off than with even a
patched non-Free one. And you're voting with your wallet. We all win!

Morally, at least in the short-to-medium term, I'm not convinced.
The smell of privilege becomes hard to ignore with the costs and other
assumptions involved.

Like you, I'm very curious to know what others think.

                                 * * *

Note: despite my musing above, I don't *actually* expect GNU Guix to
start shipping or even recommending proprietary software, including
microcode. It opens cans of worms and then the worms get everywhere.

Kind regards,

T G-R

[0]: I'll not address the question of whether a device with proprietary
firmware that you can or must update is more or less free than a device
with proprietary firmware that you can't.

Re: Meltdown / Spectre

[Leo Famulari]

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

On Tue, Jan 09, 2018 at 10:18:51PM +0100, Tobias Geerinckx-Rice wrote:
> Katherine Cox-Buday wrote on 09/01/18 at 21:13:
> > Tobias Geerinckx-Rice <me@tobias.gr> writes:
> >> [...] 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.

[...]

> > 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 :)
> 
> Logically, it's perfectly sound to extrapolate the above policy to CPUs
> and entire systems. I'm half surprised someone hasn't done so yet: buy a
> Free(er) system, and you're arguably much better off than with even a
> patched non-Free one. And you're voting with your wallet. We all win!
>
> Morally, at least in the short-to-medium term, I'm not convinced.
> The smell of privilege becomes hard to ignore with the costs and other
> assumptions involved.

I think I agree with you here, Tobias.

To me, the right choice is not to suggest that people replace almost
every general-purpose CPU that exists, but rather to help them fix these
bugs while keeping the CPU they've already paid for, and that the
Earth's ecology has already paid for. Even though microcode updates are
not free software.

This is a situation where some definition of "user safety" beats "user
control", in my estimation.

However, my understanding is that this sort of situation has been
discussed by RMS or the FSF, and even then the advice is to favor
software freedom.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Katherine Cox-Buday]

Leo Famulari <leo@famulari.name> writes:

>> Morally, at least in the short-to-medium term, I'm not convinced.
>> The smell of privilege becomes hard to ignore with the costs and other
>> assumptions involved.
>
> I think I agree with you here, Tobias.
>
> To me, the right choice is not to suggest that people replace almost
> every general-purpose CPU that exists, but rather to help them fix these
> bugs while keeping the CPU they've already paid for, and that the
> Earth's ecology has already paid for. Even though microcode updates are
> not free software.

I really appreciate the viewpoints expressed here, thank you. It's a
great reminder that software freedom doesn't exist in a vacuum, and that
its intent is to do good. It's worth considering what that means in a
more global context.

> This is a situation where some definition of "user safety" beats "user
> control", in my estimation.

I've been reading up on the philosophical differences between BSD and
GNU licenses, and one of the points that's often made is that BSD is the
freer of the two -- allowing users to do as they please -- but GNU
expresses the most freedom globally and is therefore more ethical.

It is a fun thought experiment to extrapolate and apply the same logic
to this situation: what would express the most freedom globally:
faithfully applying the GPL, or assisting users with securing their
computing environments.

Please note that I'm advocating any approach; only having a nice
discussion with like-minded folks.

-- 
Katherine

Re: Meltdown / Spectre

[Adonay Felipe Nogueira]

With regards to BSD-3-Clause-Clear and BSD-2-Clause-FreeBSD vs. GPL (and
variants), the latest version and "or-later" option of the latter allows
a chance to transfer the freedoms of the software to the end-users' copy
(it's not a perfect ingredient, because it depends on the rights holder
to enforce it but it's the necessary condition) while the former (the
BSD-likes) are too lax (the moment the rights holder decides to do
something, the person already lost the legal mechanisms that would allow
per to influence the derivative project's decision to guarantee that
end-users have their software freedom kept with the copy of the software
they have). Of course, this influence is best exercised with
collaboration for license compliance, and commitment from the
non-compliant to fix the issues. Besides, without the right amount of
regulation market moves faster than sustainability, and the permissive
nature of the first two licenses mentioned make a perfect tool for
opportunistic competitive behavior, in a century and with goods
where/which we can't spend time with Porterism nor with Social
Darwinisms.

As for the attempt to apply the same comparison to the possibility of a
microcode update: I guess it can be considered a matter of where one
wants to go. I see various projects which have some product which is
free/libre software, but have alternative products (from the same
origin) which do the same thing but which aren't free/libre, so for
those origins/projects I consider them a kind of "desperate attempt to
'reach out' to other people", even if it means not following the
free/libre software philosophy. Finally, I tend to not follow these
projects, nor recommend their free/libre products, because I find these
misleading.

2018-01-11T13:45:32-0600 Katherine Cox-Buday wrote:
> I really appreciate the viewpoints expressed here, thank you. It's a
> great reminder that software freedom doesn't exist in a vacuum, and that
> its intent is to do good. It's worth considering what that means in a
> more global context.
>
>
> I've been reading up on the philosophical differences between BSD and
> GNU licenses, and one of the points that's often made is that BSD is the
> freer of the two -- allowing users to do as they please -- but GNU
> expresses the most freedom globally and is therefore more ethical.
>
> It is a fun thought experiment to extrapolate and apply the same logic
> to this situation: what would express the most freedom globally:
> faithfully applying the GPL, or assisting users with securing their
> computing environments.
>
> Please note that I'm advocating any approach; only having a nice
> discussion with like-minded folks.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Meltdown / Spectre

[Tobias Platen]

On 09.01.2018 22:18, Tobias Geerinckx-Rice wrote:
> Katherine,
> 
> Not really an answer to your question, I'm afraid. Just some thoughts I
> had after hitting ‘Send’ on my previous non-answer.
> 
> Katherine Cox-Buday wrote on 09/01/18 at 21:13:
>> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>>> [...] 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
> 
> I don't think it's unique per se, but it is of another degree entirely
> than, for example, asking users to buy a €15 RYF-certified wireless card
> instead of pushing proprietary firmware to the one they already have.[0]
> 
> The rationale there being that freedom is worth the price, and
> (implicitly but importantly) that this price is affordable for anyone
> who values their freedom and owns a computer to begin with.
> 
> I think that's reasonable.
> 
>> 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 :)
> 
> Logically, it's perfectly sound to extrapolate the above policy to CPUs
> and entire systems. I'm half surprised someone hasn't done so yet: buy a
> Free(er) system, and you're arguably much better off than with even a
> patched non-Free one. And you're voting with your wallet. We all win!
The Talos II is a free-er system. And its processor (the POWER9) does 
not seem to be affected by Meltdown/Sprectre [1].

[1] https://mobile.twitter.com/RaptorCompSys?p=s
> 
> Morally, at least in the short-to-medium term, I'm not convinced.
> The smell of privilege becomes hard to ignore with the costs and other
> assumptions involved.
> 
> Like you, I'm very curious to know what others think.
> 
>                                   * * *
> 
> Note: despite my musing above, I don't *actually* expect GNU Guix to
> start shipping or even recommending proprietary software, including
> microcode. It opens cans of worms and then the worms get everywhere.

> 
> Kind regards,
> 
> T G-R
> 
> [0]: I'll not address the question of whether a device with proprietary
> firmware that you can or must update is more or less free than a device
> with proprietary firmware that you can't.
> 
The Free Software Foundation treats programs stored in ROM as hardware, 
this is documented in [2] and [3].
[2] https://www.gnu.org/philosophy/applying-free-sw-criteria.html
[3] https://www.fsf.org/campaigns/free-bios.html

Tobias Platem

Re: Meltdown / Spectre

[Leo Famulari]

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

On Wed, Jan 10, 2018 at 11:46:46AM +0100, Tobias Platen wrote:
> The Talos II is a free-er system. And its processor (the POWER9) does not
> seem to be affected by Meltdown/Sprectre [1].
> 
> [1] https://mobile.twitter.com/RaptorCompSys?p=s

The Talos teams says that their POWER8 and POWER9 systems are vulnerable
to Meltdown and Spectre, but that the CPUs will be patched somehow:

https://twitter.com/RaptorCompSys/status/949368929507520517

I expect any CPU that does speculative execution / executes out-of-order
will be found to be vulnerable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Christopher Lemmer Webber]

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

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.

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

Re: Meltdown / Spectre

[Kei Kebreau]

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

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Katherine Cox-Buday 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 :)
>
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Meltdown / Spectre

[Chris Marusich]

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

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Meltdown / Spectre

[Gábor Boskovits]

[-- 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 --]

Re: Meltdown / Spectre

[Alex Vong]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Hej Marius,
>
> [I see this is being CC'd to @libreboot.org. I'm answering only as a GNU
>  Guix user and contributor, and assume people who live and breathe this
>  stuff will find plenty of holes in my opinion. Which this is.]
>
> Marius Bakke wrote on 08/01/18 at 19:26:
>> In my opinion, CPU microcode falls under "non-functional data", as
>> expressly permitted by the GNU FSDG.
>
> I'm not sure how tongue-in-cheek this is, so I'm not sure how to
> respond. I hope nobody on the Internet is wrong^Wseriously suggesting
> that microcode or any other firmware isn't machine code and —
> unfortunately for everyone everywhere — very (dis)functional indeed.
>
> (Don't get me wrong: I wish it weren't so, or that there were some sort
>  of commonly-agreed-upon wink-nudge fiction that it wasn't. If there is,
>  then Debian isn't playing along: microcode blobs are ‘non-free’[0].)
>
> 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?
>
For this particular question, I think we can point users to this
discussion thread in the news section for example. Then they can decide
for themselves what to do. I think this is close to the best thing we
can do now.

>> It is not required for the processor to function, it is merely *a
>> posteriori* data that the CPU can use to fix erratic behaviour.
>
> AIUI, at least on x86 CPUs, the microcode *is* a large and/or functional
> part of the processor. I suspect that's the case for most sufficiently
> modern (complex) chips, but it's not my field.
>
Agree, in my assembly programming course, the lecturer mentioned that
(if I recall correctly) a mircrocode update can bring new instruction
set to a CPU, so it is a very programmable part of the CPU.

> Kind regards,
>
> T G-R
>
> [0]: https://lists.debian.org/debian-devel/2012/11/msg00109.html,
>      https://packages.debian.org/search?keywords=microcode

Re: Meltdown / Spectre

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
>> Chris Marusich <cmmarusich@gmail.com> writes:
>>
>>> Leo Famulari <leo@famulari.name> writes:
>>
>>> I wonder: how easy will it be to install those firmware/microcode
>>> updates if you are using GuixSD? In particular, I'm curious about the
>>> case of the Lenovo x200 with libreboot, since that's what I use
>>> personally.
>>
>> I am also interested -- more from a philisophical perspective -- how
>> GuixSD and GNU squares with these kinds of security updates.
>
> In my opinion, CPU microcode falls under "non-functional data", as
> expressly permitted by the GNU FSDG.

I strongly disagree.  CPU microcode is absolutely functional data.
It determines how the CPU functions.

> It is not required for the processor to function, it is merely *a
> posteriori* data that the CPU can use to fix erratic behaviour.

Microcode *is* required for the processor to function.  Upgrading it is
optional, because the CPU contains a copy of the microcode in its ROM,
but that doesn't change the fact that the microcode is required.

By the same argument that you presented here, any proprietary software
(e.g. a BIOS) would be considered optional and therefore non-functional
data as long as an older copy of that software is included in the
hardware of the machine.

       Mark

Re: Meltdown / Spectre

[Leo Famulari]

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

On Tue, Jan 09, 2018 at 06:10:02PM -0500, Mark H Weaver wrote:
> Marius Bakke <mbakke@fastmail.com> writes:
> > Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
> >> I am also interested -- more from a philisophical perspective -- how
> >> GuixSD and GNU squares with these kinds of security updates.
> >
> > In my opinion, CPU microcode falls under "non-functional data", as
> > expressly permitted by the GNU FSDG.
> 
> I strongly disagree.  CPU microcode is absolutely functional data.
> It determines how the CPU functions.

Personally I would really like to have microcode deployment integrated
into GuixSD. But I agree with Mark here, and I don't see how it can be
reconciled with the FSDG.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Meltdown / Spectre

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Tue, Jan 09, 2018 at 06:10:02PM -0500, Mark H Weaver wrote:
>> Marius Bakke <mbakke@fastmail.com> writes:
>> > Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>> >> I am also interested -- more from a philisophical perspective -- how
>> >> GuixSD and GNU squares with these kinds of security updates.
>> >
>> > In my opinion, CPU microcode falls under "non-functional data", as
>> > expressly permitted by the GNU FSDG.
>> 
>> I strongly disagree.  CPU microcode is absolutely functional data.
>> It determines how the CPU functions.
>
> Personally I would really like to have microcode deployment integrated
> into GuixSD. But I agree with Mark here, and I don't see how it can be
> reconciled with the FSDG.

Agreed.  Updated microcode can surely be considered software, and per
the FSDG we will not distribute it.

Should GuixSD nevertheless provide a mechanism to support microcode
updates, while not steering users to particular proprietary microcode?
Just like Linux-libre (attempts to) support loading of proprietary
firmware at the user’s choice?  Would it make sense at all?

The Intel CPU situation is terrible from a user freedom POV and there
are no signs of it getting better.  I think the free software community
must stand strong against it.

Ludo’.

Re: Meltdown / Spectre

[Mike Gerwitz]

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

On Tue, Jan 16, 2018 at 12:10:53 +0100, Ludovic Courtès wrote:
> Should GuixSD nevertheless provide a mechanism to support microcode
> updates, while not steering users to particular proprietary microcode?
> Just like Linux-libre (attempts to) support loading of proprietary
> firmware at the user’s choice?  Would it make sense at all?

Does Linux-Libre specifically support loading proprietary firmware, or
does the project phrase it as _any_ firmware, free or not, that the user
may provide?

My point being: if there only exists proprietary microcode, it's hard to
make the argument that a freedom-respecting user will use a microcode
update tool for anything other than proprietary software.  In that case,
does the inclusion of the microcode updater in Guix encourage the use of
non-free microcode, even if it doesn't state where to get it?

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Meltdown / Spectre

[Ludovic Courtès]

Mike Gerwitz <mtg@gnu.org> skribis:

> On Tue, Jan 16, 2018 at 12:10:53 +0100, Ludovic Courtès wrote:
>> Should GuixSD nevertheless provide a mechanism to support microcode
>> updates, while not steering users to particular proprietary microcode?
>> Just like Linux-libre (attempts to) support loading of proprietary
>> firmware at the user’s choice?  Would it make sense at all?
>
> Does Linux-Libre specifically support loading proprietary firmware, or
> does the project phrase it as _any_ firmware, free or not, that the user
> may provide?

It obviously supports loading free firmware like what we provide in
Guix.  However, firmware is searched for under a specific file name, you
can tell that some of these correspond to proprietary firmware only.

Now, I wrote “attempts to” because my understanding is that, even though
the project intends to permit it, the deblobbling code often/always
breaks the non-free firmware loading code.

> My point being: if there only exists proprietary microcode, it's hard to
> make the argument that a freedom-respecting user will use a microcode
> update tool for anything other than proprietary software.  In that case,
> does the inclusion of the microcode updater in Guix encourage the use of
> non-free microcode, even if it doesn't state where to get it?

Right, it’s a valid argument.

Thanks,
Ludo’.

Re: Meltdown / Spectre

[Chris Marusich]

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

Alex Vong <alexvong1995@gmail.com> writes:

> Hello,
>
> I hope this is on topic. Recently, 2 critical vulnerabilities (see
> https://meltdownattack.com/) affecting virtually all intel cpus are
> discovered. I am running libreboot x200 (see
> https://www.fsf.org/ryf). What should I do right now to patch my laptop?
>
> Cheers,
> Alex

According to the user named _4of7 in the #libreboot channel of the
Freenode IRC network, the email list development@libreboot.org is down.
So the Libreboot maintainers have probably not seen this email thread.

According to _4of7, currently the best way to contact the Libreboot
maintainers is IRC.  It would probably be best to ask there.  If you get
a response, please don't forget to update us here on this thread!

When I asked in #freenode today, _4of7 responded as follows:

  <_4of7> There's not much we can do from the Libreboot side, but there are
  <_4of7> mitigations on kernel side... since it's exploitable from javascript
  <_4of7> you could also e.g. not run JavaScript. specing on #libreboot IRC had
  <_4of7> the idea to run Firefox without the JIT enabled - we both tried to
  <_4of7> compile the latest ESR however, with --disable-ion, and it segfaulted.
  <_4of7> I tried to build ff 45esr instead, but that build failed.

I'm not sure who _4of7 is, so I don't know if they speak for the
Libreboot project.

Mark H Weaver <mhw@netris.org> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>>
>>> Chris Marusich <cmmarusich@gmail.com> writes:
>>>
>>>> Leo Famulari <leo@famulari.name> writes:
>>>
>>>> I wonder: how easy will it be to install those firmware/microcode
>>>> updates if you are using GuixSD? In particular, I'm curious about the
>>>> case of the Lenovo x200 with libreboot, since that's what I use
>>>> personally.
>>>
>>> I am also interested -- more from a philisophical perspective -- how
>>> GuixSD and GNU squares with these kinds of security updates.
>>
>> In my opinion, CPU microcode falls under "non-functional data", as
>> expressly permitted by the GNU FSDG.
>
> I strongly disagree.  CPU microcode is absolutely functional data.
> It determines how the CPU functions.

Does the GNU Project have a policy regarding this sort of thing?  I
wasn't able to find any articles on gnu.org that discuss it.

If no such policy exists, then should this topic be discussed somewhere
like gnu-system-discuss@gnu.org?  I don't know where discussions like
this normally take place within the GNU project.  It's definitely a
discussion worth having, though.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Meltdown / Spectre

[Adonay Felipe Nogueira]

I don't know if this serves as guidance as to if microcode is functional
or not, but from [1] I quote:

#+BEGIN_QUOTE

However, there is an exception for secondary embedded processors. The
exception applies to software delivered inside auxiliary and low-level
processors and FPGAs, within which software installation is not intended
after the user obtains the product. This can include, for instance,
microcode inside a processor, firmware built into an I/O device, or the
gate pattern of an FPGA. The software in such secondary processors does
not count as product software.

#+END_QUOTE

My (perhaps uninformed) opinion is that it's functional data, but not
the sort of "functional" that every human would be allowed to modify
after it was first written.

[1] <https://www.fsf.org/resources/hw/endorsement/criteria>.

2018-01-10T01:36:18-0800 Chris Marusich wrote:
> According to the user named _4of7 in the #libreboot channel of the
> Freenode IRC network, the email list development@libreboot.org is down.
> So the Libreboot maintainers have probably not seen this email thread.
>
> According to _4of7, currently the best way to contact the Libreboot
> maintainers is IRC.  It would probably be best to ask there.  If you get
> a response, please don't forget to update us here on this thread!
>
> When I asked in #freenode today, _4of7 responded as follows:
>
>   <_4of7> There's not much we can do from the Libreboot side, but there are
>   <_4of7> mitigations on kernel side... since it's exploitable from javascript
>   <_4of7> you could also e.g. not run JavaScript. specing on #libreboot IRC had
>   <_4of7> the idea to run Firefox without the JIT enabled - we both tried to
>   <_4of7> compile the latest ESR however, with --disable-ion, and it segfaulted.
>   <_4of7> I tried to build ff 45esr instead, but that build failed.
>
> I'm not sure who _4of7 is, so I don't know if they speak for the
> Libreboot project.
>
>
> Does the GNU Project have a policy regarding this sort of thing?  I
> wasn't able to find any articles on gnu.org that discuss it.
>
> If no such policy exists, then should this topic be discussed somewhere
> like gnu-system-discuss@gnu.org?  I don't know where discussions like
> this normally take place within the GNU project.  It's definitely a
> discussion worth having, though.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Meltdown / Spectre

[Tobias Platen]

On 10.01.2018 12:49, Adonay Felipe Nogueira wrote:
> I don't know if this serves as guidance as to if microcode is functional
> or not, but from [1] I quote:
> 
> #+BEGIN_QUOTE
> 
> However, there is an exception for secondary embedded processors. The
> exception applies to software delivered inside auxiliary and low-level
> processors and FPGAs, within which software installation is not intended
> after the user obtains the product. This can include, for instance,
> microcode inside a processor, firmware built into an I/O device, or the
> gate pattern of an FPGA. The software in such secondary processors does
> not count as product software.
As an example there is still proprietary formware on the embedded 
controller of the Thinkpads supported by libreboot.
> 
> #+END_QUOTE
> 
> My (perhaps uninformed) opinion is that it's functional data, but not
> the sort of "functional" that every human would be allowed to modify
> after it was first written.
> 
> [1] <https://www.fsf.org/resources/hw/endorsement/criteria>.
> 
> 2018-01-10T01:36:18-0800 Chris Marusich wrote:
>> According to the user named _4of7 in the #libreboot channel of the
>> Freenode IRC network, the email list development@libreboot.org is down.
>> So the Libreboot maintainers have probably not seen this email thread.
>>
>> According to _4of7, currently the best way to contact the Libreboot
>> maintainers is IRC.  It would probably be best to ask there.  If you get
>> a response, please don't forget to update us here on this thread!
>>
>> When I asked in #freenode today, _4of7 responded as follows:
>>
>>    <_4of7> There's not much we can do from the Libreboot side, but there are
>>    <_4of7> mitigations on kernel side... since it's exploitable from javascript
>>    <_4of7> you could also e.g. not run JavaScript. specing on #libreboot IRC had
>>    <_4of7> the idea to run Firefox without the JIT enabled - we both tried to
>>    <_4of7> compile the latest ESR however, with --disable-ion, and it segfaulted.
>>    <_4of7> I tried to build ff 45esr instead, but that build failed.
>>
>> I'm not sure who _4of7 is, so I don't know if they speak for the
>> Libreboot project.
Leah Rowe uses the nickname _4of7 on IRC, she is the founder of Libreboot
>>
>>
>> Does the GNU Project have a policy regarding this sort of thing?  I
>> wasn't able to find any articles on gnu.org that discuss it.
>>
>> If no such policy exists, then should this topic be discussed somewhere
>> like gnu-system-discuss@gnu.org?  I don't know where discussions like
>> this normally take place within the GNU project.  It's definitely a
>> discussion worth having, though.
> 

Re: Meltdown / Spectre

[Gábor Boskovits]

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

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.

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

Re: Meltdown / Spectre

[Marius Bakke]

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

Gábor Boskovits <boskovits@gmail.com> writes:

> 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.

FWIW there is a tool that does this in Guix already: "iucode-tool".

Here is the latest microcode from Intel:

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

Unfortunately it does not contain any updates for my two Sandy Bridge
systems.  So while this discussion is very interesting (and important),
there doesn't seem to be any remediation for systems older than 3-4
years, leaving pretty much all Libreboot systems in the dirt.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Meltdown / Spectre

[Pjotr Prins]

On Wed, Jan 10, 2018 at 03:04:44PM +0100, Gábor Boskovits wrote:
>    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.

I agree with you. The fact that we run untrusted hardware hardly gets
improved if we can't fix it ;). GNU Guix, however, by virtue of being
a GNU project is hampered by its free software credentials. We have to
do what people expect from free software.

The only way around this is to provide tooling outside GNU Guix.
Fortunately that is not too hard since microcode is independent
of the rest of the tooling. We could create a channel for this,
something to discuss at FOSDEM. Channels provide a workaround for
purely free software - one reason some of us are reluctant to
introduce them. You can see microcode patches coming for other
hardware too.

Pj.
-- 

Re: Meltdown / Spectre

[Mike Gerwitz]

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

On Mon, Jan 15, 2018 at 09:07:45 +0100, Pjotr Prins wrote:
> GNU Guix, however, by virtue of being a GNU project is hampered by its
> free software credentials.

"hamper" isn't a good word to use to describe the FSDG:

  From The Collaborative International Dictionary of English v.0.48 [gcide]:
  
    Hamper \Ham"per\, n. [See {Hamper} to shackle.]
       1. A shackle; a fetter; anything which impedes. --W. Browne.
          [1913 Webster]
    
  From The Collaborative International Dictionary of English v.0.48 [gcide]:
  
    Hamper \Ham"per\, v. t. [OE. hamperen, hampren, prob. of the
       same origin as E. hamble.]
       To put a hamper or fetter on; to shackle; to insnare; to
       inveigle; to entangle; hence, to impede in motion or
       progress; to embarrass; to encumber. "Hampered nerves."
       --Blackmore.
       [1913 Webster]
    
             A lion hampered in a net.                --L'Estrange.
       [1913 Webster]
    
             They hamper and entangle our souls.      --Tillotson.
       [1913 Webster]

The FSDG is mean to liberate, not hamper; we're all stronger because
of Guix's adherence to it.  This is perhaps the only occasion I can
think of---and is admittedly very awkward---where the software running
on a computer is considered fine if we pretend that it doesn't exist as
software, but becomes a problem if we recognize its existence and
attempt to update it.  This is a conflict that needs resolution, but I'm
not offering that here---I just wanted to comment on the phrasing.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Meltdown / Spectre

[Pjotr Prins]

On Mon, Jan 15, 2018 at 10:08:56PM -0500, Mike Gerwitz wrote:
> On Mon, Jan 15, 2018 at 09:07:45 +0100, Pjotr Prins wrote:
> > GNU Guix, however, by virtue of being a GNU project is hampered by its
> > free software credentials.
> 
> "hamper" isn't a good word to use to describe the FSDG:

Shackled then ;)

I do think these breaches can lead to serious exploits, even though
taking over a computer (which is the real concern) may be very hard to
achieve and may never happen reading 'random' data. Intels management
system is a much worse and direct threat. Addressing the meltdown/spectre
breach is a good thing, but maybe a bit overrated as a threat if I
understand it correctly.

The good news, still, is that this may lead to new hardware. The time
should be close that it becomes feasible to design open hardware CPUs
and have them distributed at some scale. Security may be a great
driver. I'll buy them even if they are half the performance
of Intel offerings. Especially when they use a lot less power. There
is a nice market for that.

Pj.

Re: Meltdown / Spectre

[Chris Marusich]

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

Tobias Platen <trisquel@platen-software.de> writes:

> Leah Rowe uses the nickname _4of7 on IRC, she is the founder of Libreboot

I see - I did not know.  Thank you for clarifying that!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]