Microcode updates for slightly older intel CPU's re: meltdown/spectre

      I am curious of any intel insiders know if there will be microcode 
updates released for older intel CPU's (ex: sandy/ivybridge) and failing 
that, what can be done in regards to securing them from meltdown/spectre.

I believe this is a relevant coreboot topic considering how many 
coreboot boards have these and older CPU's....without a fix there will 
be only one coreboot compatible laptop with open source hardware 
initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD 
CPU) and theoretically owner controllable (as the previous C2D/C2Q's 
such as the X200 are now permanently insecure without intervention from 
intel apparently)

At this point even a massive performance loss is better than having to 
throw out so much now-useless hardware.

[[799]]

      Hello,

Off-topic:
Top-posted as Protonmail Android App is still unable to correctly use inline answers
without correct quote layout/line breaks. Bug has been reported months ago :-/

Taiidan wrote:

"(...) CPU's....without a fix there will
be only one coreboot compatible laptop with open source hardware
initiation that is remotely secure (...)"

Currently I am using two laptops for my work setup:
A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with Qubes
OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the x230 is running
Coreboot.

Honestly I am shocked and angry if there will be no Intel Updates for the X230 and W540.
On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce the risk
of Meltdown/Spectre attacks as Coreboot will protect me against remote attacks (stripped
down AMT/Intel ME) and Qubes might reduce the attack surface as I am using several VMs and
DVMs for browsing?

If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: the G505s is
targeted at another audience that Lenovo ThinkPad Users. It looks to me like an entry
level desktop, which is also very bulky (without the additional performance of a W540).

CPU comparison X230 CPU vs G505s
http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M...

Also the G505s has less cores/no HT

Frustration. Can't "we" build one or maybe two crowd founded secure Laptops
(12", 15.x") with reasonable specs, good keyboard, hardware kill switches,
internal wan (kill-switchable)?
I can't think that choice is limited in 2018 to only 1 (in words "one")
laptop modell, which is no nearly 5 years old (08/2013).

Brave new world.

[799]

Gesendet von ProtonMail mobile

-------- Original-Nachricht --------
An 11. Jan. 2018, 03:55, Taiidan(a)gmx.com schrieb:

  I am curious of any intel insiders know if there will
be microcode
 updates released for older intel CPU's (ex: sandy/ivybridge) and failing
 that, what can be done in regards to securing them from meltdown/spectre.

 I believe this is a relevant coreboot topic considering how many
 coreboot boards have these and older CPU's....without a fix there will
 be only one coreboot compatible laptop with open source hardware
 initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD
 CPU) and theoretically owner controllable (as the previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)

 At this point even a massive performance loss is better than having to
 throw out so much now-useless hardware.

 --
 coreboot mailing list: coreboot(a)coreboot.org
 https://mail.coreboot.org/mailman/listinfo/coreboot

[Merlin Büge]

On Wed, 10 Jan 2018 21:55:18 -0500
&quot;Taiidan(a)gmx.com&quot; <Taiidan(a)gmx.com&gt; wrote:

  I am curious of any intel insiders know if there will
be microcode 
 updates released for older intel CPU's (ex: sandy/ivybridge) and
 failing that, what can be done in regards to securing them from
 meltdown/spectre.
Not an Intel insider, but here is a list from Lenovo listing affected
products and when microcode updates will be available addressing
Spectre v2:

  https://support.lenovo.com/de/en/solutions/len-18282

X230 is scheduled for 2/2/2018.

I don't know about the X200, but I doubt there will be further microcede
updates :/ But actually I don't know.


For meltdown, running the latest kernel should be sufficient I guess,
since it has the KPTI patches.


  
 I believe this is a relevant coreboot topic considering how many 
 coreboot boards have these and older CPU's....without a fix there
 will be only one coreboot compatible laptop with open source hardware 
 initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD 
 CPU) and theoretically owner controllable (as the previous C2D/C2Q's 
 such as the X200 are now permanently insecure without intervention
 from intel apparently)
 
 At this point even a massive performance loss is better than having
 to throw out so much now-useless hardware.
 
 
 -- 
 coreboot mailing list: coreboot(a)coreboot.org
 https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
Merlin Büge <toni(a)bluenox07.de&gt;

[Nico Huber]

      Hi Taiidan,

On 11.01.2018 03:55, Taiidan(a)gmx.com wrote:
  I am curious of any intel insiders know if there will
be microcode
 updates released for older intel CPU's (ex: sandy/ivybridge) and failing
 that, what can be done in regards to securing them from meltdown/spectre.
 
 I believe this is a relevant coreboot topic considering how many
 coreboot boards have these and older CPU's....without a fix there will
 be only one coreboot compatible laptop with open source hardware
 initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD
 CPU) and theoretically owner controllable
you seem to be misinformed about the G505s. There is no open-source gfx
init for AMD (not in firmware, not in the OS), so within your require-
ments it's not usable as a laptop.

  (as the previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
It depends on the software you run. Please read more about Meltdown and
Spectre. When you understood it, you can still start to worry.

  
 At this point even a massive performance loss is better than having to
 throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.

Nico

[awokd]

      On Thu, January 11, 2018 10:05 am, Nico Huber wrote:

  On 11.01.2018 03:55, Taiidan(a)gmx.com wrote:
  only one
coreboot compatible laptop with open source hardware initiation
 that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and
 theoretically owner controllable
 you seem to be misinformed about the G505s. There is no open-source gfx
 init for AMD (not in firmware, not in the OS), so within your require-
 ments it's not usable as a laptop.
In its defense, it's one of the few usable laptops that don't have ME or
PSP. I did a full Debian kernel build inside a Xen HVM on it the other day
in 2.5 hours. I'm sure there's faster but for day to day use it's plenty
good for me, even though I do need to tolerate a handful of blobs.

      On 01/11/2018 05:05 AM, Nico Huber wrote:

  you seem to be misinformed about the G505s. There is
no open-source gfx
 init for AMD (not in firmware, not in the OS), so within your require-
 ments it's not usable as a laptop.
I forgot to include my usual suffix
mentioning that blobs are required 
for video (and power management)

I believe it is still much better than the C2D laptops in terms of 
security despite the video blob as it has an IOMMU [1] and no ME/PSP.
[1] with the high end quad core CPU option
  (as the
previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
 It depends on the software you run. Please read more about
Meltdown and
 Spectre. When you understood it, you can still start to worry.

  At this point even a massive performance loss is
better than having to
 throw out so much now-useless hardware.
 Yes? and that can be accomplished without
microcode updates, AFAIK.
I was and still am under the impression that fixing both
issue classes 
requires microcode updates, can you link to a better explanation?

[Timothy Pearson]

      -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What I'm more concerned about right now is something I'd term "security
apathy".  We just learned 99% of the world's computers are insecure in
one way or another; security is now something that (to most people)
apparently cannot be purchased.  In such an environment, the cheapest
system per unit performance always wins, even if it happens to contain
rampant abuses of privacy / backdoors.

Probably a discussion best had over coffee, since it's largely
unfixable, but suffice it to say we're already starting to see this even
in our original customer base.

On 01/11/2018 04:22 PM, Taiidan(a)gmx.com wrote:
  On 01/11/2018 05:05 AM, Nico Huber wrote:
 
  you seem to be misinformed about the G505s. There
is no open-source gfx
 init for AMD (not in firmware, not in the OS), so within your require-
 ments it's not usable as a laptop.
 I forgot to include my usual suffix
mentioning that blobs are required
 for video (and power management)
 
 I believe it is still much better than the C2D laptops in terms of
 security despite the video blob as it has an IOMMU [1] and no ME/PSP.
 [1] with the high end quad core CPU option
  (as the
previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
 It depends on the software you run. Please read more about
Meltdown and
 Spectre. When you understood it, you can still start to worry.

  At this point even a massive performance loss is
better than having to
 throw out so much now-useless hardware.
 Yes? and that can be accomplished without
microcode updates, AFAIK.
 I was and still am under the impression that fixing both
issue classes
 requires microcode updates, can you link to a better explanation?

- -- 
Timothy Pearson
Raptor Engineering
[phone] (direct line)
[phone] (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J
XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml
59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw
U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq
O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg
X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0=
=gkEr
-----END PGP SIGNATURE-----

[Alberto Bursi]

      This assumes security was a concern in the first place, which is not 
what I see where I live/work.


On 01/11/2018 11:27 PM, Timothy Pearson wrote:
  -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 What I'm more concerned about right now is something I'd term "security
 apathy".  We just learned 99% of the world's computers are insecure in
 one way or another; security is now something that (to most people)
 apparently cannot be purchased.  In such an environment, the cheapest
 system per unit performance always wins, even if it happens to contain
 rampant abuses of privacy / backdoors.

 Probably a discussion best had over coffee, since it's largely
 unfixable, but suffice it to say we're already starting to see this even
 in our original customer base.

 On 01/11/2018 04:22 PM, Taiidan(a)gmx.com wrote:
  On 01/11/2018 05:05 AM, Nico Huber wrote:

  you seem to be misinformed about the G505s. There
is no open-source gfx
 init for AMD (not in firmware, not in the OS), so within your require-
 ments it's not usable as a laptop.
 I forgot to include my usual suffix mentioning that blobs are required
 for video (and power management)

 I believe it is still much better than the C2D laptops in terms of
 security despite the video blob as it has an IOMMU [1] and no ME/PSP.
 [1] with the high end quad core CPU option
  (as the
previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
 It depends on the software you run. Please read more about Meltdown and
 Spectre. When you understood it, you can still start to worry.

  At this point even a massive performance loss is
better than having to
 throw out so much now-useless hardware.
 Yes? and that can be accomplished without microcode updates, AFAIK.
 I was and still am under the impression that fixing both issue classes
 requires microcode updates, can you link to a better explanation?

 - -- 
 Timothy Pearson
 Raptor Engineering
 [phone] (direct line)
 [phone] (switchboard)
 https://www.raptorengineering.com
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1

 iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J
 XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml
 59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw
 U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq
 O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg
 X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0=
 =gkEr
 -----END PGP SIGNATURE-----

[Merlin Büge]

      On Thu, 11 Jan 2018 17:22:48 -0500
&quot;Taiidan(a)gmx.com&quot; <Taiidan(a)gmx.com&gt; wrote:

  On 01/11/2018 05:05 AM, Nico Huber wrote:
 
  you seem to be misinformed about the G505s. There
is no open-source
 gfx init for AMD (not in firmware, not in the OS), so within your
 require- ments it's not usable as a laptop.
 I forgot to include my usual
suffix mentioning that blobs are
 required for video (and power management)
 
 I believe it is still much better than the C2D laptops in terms of 
 security despite the video blob as it has an IOMMU [1] and no ME/PSP.
 [1] with the high end quad core CPU option
  (as the
previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention
 from intel apparently)
 It depends on the software you run. Please read more about
Meltdown
 and Spectre. When you understood it, you can still start to worry.

  At this point even a massive performance loss is
better than
 having to throw out so much now-useless hardware.
 Yes? and that can be
accomplished without microcode updates, AFAIK.
 I was and still am under the
impression that fixing both issue
 classes requires microcode updates, can you link to a better
 explanation?
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Anal...



  
 -- 
 coreboot mailing list: coreboot(a)coreboot.org
 https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
Merlin Büge <toni(a)bluenox07.de&gt;

[Mike Banon]

      Hi Nico,

 
 you seem to be misinformed about the G505s. There is no
 open-source gfx init for AMD (not in firmware, not in the OS),
 so within your requirements it's not usable as a laptop
I've had a small discussion with bridgman from AMD (at Phoronix forums)
and he told me that VBIOS needed by G505S - aka "gfx init for AMD" -
- is "effectively open source" - a byte code which is possible to parse
with [AtomDis] open source interpreter

Only problem is that the last update of AtomDis was at 2011 - so, while it
should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes
(because these GPUs were developed before 2011 if I am correct)
maybe AtomDis couldn't parse everything for the modern AMD GPUs

Me:

" @bridgman why you don't just open source the complete source code of
VBIOS, to let the open source community improve it and fix some bugs?
With the help of flashrom open source project, anyone is able to
reflash their VBIOS through In-System-Programming. We just don't have
the original source code of VBIOS, and the creation of open source
VBIOS from scratch is like reinventing the wheel - a huge wheel, which
is way too much for unpaid work

Just share the complete source code of VBIOS and let the open source
community fix the bugs for you for free! A win-win solution. Why not
do it? For the bystanders like me, it gives an impression that either
1) VBIOS source code is a horrible quality, too ashamed to release it
to public 2) VBIOS contains some hidden backdoors, hence the need for
secrecy 3) AMD is not that friendly to open source community, if
instead of sharing what you already got, you want the people to start
reinventing the wheel and waste countless of unpaid work hours on it "

brigman:

" It is effectively open source. The data tables are all documented in
atombios.h. They are just data structures. The command table
parameters are all documented in atombios.h (also just data
structures). The command tables are all written in byte code to begin
with. The source to the interpreter is open source so you can dump
command tables and see exactly what they are doing. You can even write
your own command tables in byte code or edit exiting ones if you
wanted to. Those are the only things the driver uses from the vbios.
The whole point of the data and command tables is to encapsulate board
specific configuration details on the actual board itself so that the
driver doesn't need explicit knowledge about every board configuration
out there.

To summarize:

1. We use an interpreter in VBIOS in order to (a) fit a lot of
functionality into a small ROM, (b) give us a degree of CPU
independence. My understanding is that this is pretty common practice;
either way it's not likely to change unless OEMs buying AMD chips are
willing to spend more $$ on the ROM for our hardware than for
competitors hardware AND we are willing to go back to having different
BIOS code for each of the different CPUs our chips are used with.

2. As agd5f said, the VBIOS source code is bytecode similar to what
you get out of the disassembler, although the disassembler output is
formatted more neatly. It's not like there is a single master copy of
VBIOS source written in C that could be "opened once" - every HW
vendor tweaks their BIOS images before production and AFAIK those
changes are not ours to publish.

Relatively more of the changes are in data tables than in command
tables but both get changed and so we need to use both in the driver
if we want driver functionality to correctly match the HW config.
There are literally thousands of different HW subsystems, each with
their own VBIOS image and hence each with their own slightly different
source code... and the associated HW differences DO generally need to
be considered when the driver runs.

3. A couple of people have started projects to replace VBIOS with a
fully open solution, but my impression is that they all run into the
same issues:

- initial implementation is straightforward but ongoing maintenance is
a big and boring effort nobody wants to own
- you lose CPU independence unless you are willing to maintain AND
TEST a lot more different VBIOS builds
- without an interpreter the resulting implementation won't fit in the
on-card ROM unless you cut back functionality

We make enough information for an open source BIOS replacement
available as part of the open source driver effort (data table &
command table headers, bytecode interpreter, open source drivers using
the tables) although I don't think we support VBIOS re-flashing in
general. It is easy to get the same result by over-riding tables in
the driver code, however, and I believe there is an existing quirk
mechanism.

4. Over time I think you will see a trend away from using AtomBIOS
calls simply because ROM size limits the amount of complexity that can
be supported in ROM-resident tables while HW complexity is continuing
to grow as quickly as ever.

My understanding is that DAL/DC makes somewhat less use of AtomBIOS
calls but it also replaces a relatively painless sharing model
(drivers for all OSes/platforms make the same AtomBIOS calls for the
fiddly HW-specific bits) with a much-harder-to-sell sharing model
(drivers for all OSes/platforms share native driver code for the
fiddly HW-specific bits).

I understand that this seems unnecessary (and maybe even
counter-productive) if you believe that modesetting is trivial, but I
don't know how to reconcile your views on modesetting with the views
of developers working on the code at different vendors. Once we figure
out how to close that gap the rest of the discussion should become
easier. "

Best regards,
Mike Banon

On Thu, Jan 11, 2018 at 1:05 PM, Nico Huber <nico.h(a)gmx.de&gt; wrote:
  Hi Taiidan,

 On 11.01.2018 03:55, Taiidan(a)gmx.com wrote:
  I am curious of any intel insiders know if there
will be microcode
 updates released for older intel CPU's (ex: sandy/ivybridge) and failing
 that, what can be done in regards to securing them from meltdown/spectre.

 I believe this is a relevant coreboot topic considering how many
 coreboot boards have these and older CPU's....without a fix there will
 be only one coreboot compatible laptop with open source hardware
 initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD
 CPU) and theoretically owner controllable
 you seem to be misinformed about the G505s. There is no open-source gfx
 init for AMD (not in firmware, not in the OS), so within your require-
 ments it's not usable as a laptop.

  (as the previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
 It depends on the software you run. Please read more about Meltdown and
 Spectre. When you understood it, you can still start to worry.

 
 At this point even a massive performance loss is better than having to
 throw out so much now-useless hardware.
 Yes? and that can be accomplished without microcode updates, AFAIK.

 Nico

 --
 coreboot mailing list: coreboot(a)coreboot.org
 https://mail.coreboot.org/mailman/listinfo/coreboot

[David Hobach]

      On 01/11/2018 03:55 AM, Taiidan(a)gmx.com wrote:
  I am curious of any intel insiders know if there will
be microcode 
 updates released for older intel CPU's (ex: sandy/ivybridge) and failing 
 that, what can be done in regards to securing them from meltdown/spectre.
Looks like they're available now. Has anyone tested them yet?

https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode...

[Martin Kepplinger]

      Am 14.03.2018 22:46 schrieb David Hobach:
  On 01/11/2018 03:55 AM, Taiidan(a)gmx.com wrote:
  I am curious of any intel insiders know if there
will be microcode 
 updates released for older intel CPU's (ex: sandy/ivybridge) and 
 failing that, what can be done in regards to securing them from 
 meltdown/spectre.
 
 Looks like they're available now. Has anyone tested them yet?
 
 https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode...
I have. I have the relevant patchset up for review: 
https://review.coreboot.org/#/c/blobs/+/23315/
and currently always apply it on top of my coreboot build (for the 
Thinkpad X230 in
my case; has then revision "1f" and verified functionality using 
https://github.com/speed47/spectre-meltdown-checker
or similar tools)

                                         martin

      So you are saying that sandy and ivybridge have spectre microcode updates?

I hate how unclear intel is about this.

How do I patch my coreboot?

[Merlin Büge]

  So you are saying that sandy and ivybridge have
spectre microcode
 updates?
 
 I hate how unclear intel is about this.
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-...


-- 
Merlin Büge

[Martin Kepplinger]

      Am 20.03.2018 00:15 schrieb Taiidan(a)gmx.com:
  So you are saying that sandy and ivybridge have
spectre microcode 
 updates?
 
 I hate how unclear intel is about this.
 
 How do I patch my coreboot?
Like I said, the update is here for anybody to cherry-pick and test:
https://review.coreboot.org/#/c/blobs/+/23315/

I expect this change to be merged sometime "soon", when reviewed.

Yes, they even updated sandybridge and ivybridge. (For those, you
only need the first of those 4 patches)

Intel doesn't seem to care about informing users directly, at least this 
time around.
They've worked with and for their "industry partners" and have left
packaging updates to BIOS vendors. In the end we have a full release
from Intel again though, so we're happy at last :)

                          martin

      On 03/20/2018 04:17 AM, Martin Kepplinger wrote:

  Yes, they even updated sandybridge and ivybridge. (For
those, you
 only need the first of those 4 patches)
There are some of the last released high
end xeon/core 771/775 CPU's 
getting updates in the future too.

      Yeah I tried that but it didn't work.

git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 &&
git cherry-pick FETCH_HEAD

warning: no common commits
remote: Counting objects: 555, done
remote: Finding sources: 100% (30/30)
remote: Total 1426 (delta 1), reused 1418 (delta 1)
Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done.
Resolving deltas: 100% (396/396), done.
 From https://review.coreboot.org/blobs
 *
branch                  refs/changes/15/23315/6 -> FETCH_HEAD
error: could not apply 4f04985590... cpu: intel: microcode update for
currently tracked models to 20180312
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit

What do I do now? I have never used git before.

These patches need to be added stat - the stakes are too high for this
to take months.

[Nico Huber]

      On 20.03.2018 22:25, Taiidan(a)gmx.com wrote:
  Yeah I tried that but it didn't work.
 
 git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 &&
 git cherry-pick FETCH_HEAD
 
 warning: no common commits
 remote: Counting objects: 555, done
 remote: Finding sources: 100% (30/30)
 remote: Total 1426 (delta 1), reused 1418 (delta 1)
 Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done.
 Resolving deltas: 100% (396/396), done.
 From https://review.coreboot.org/blobs
  * branch                  refs/changes/15/23315/6 -> FETCH_HEAD
 error: could not apply 4f04985590... cpu: intel: microcode update for
 currently tracked models to 20180312
 hint: after resolving the conflicts, mark the corrected paths
 hint: with 'git add <paths>' or 'git rm <paths>'
 hint: and commit the result with 'git commit
 
 What do I do now? I have never used git before.
It's probably easier for you if you load the microcode update from your
OS.

  
 These patches need to be added stat
You obviously have no idea what you are talking about. AFAIK, nobody who
has the right to submit to the blobs repository has commented yet on
newer microcode updates or was asked personally if this is acceptable.
You might have noticed that microcode updates are not public domain but
licensed.

  - the stakes are too high for this
 to take months.
You still didn't get what Spectre is about, did you? It's just one of
many side-channel attacks that are possible when you run untrusted code
on your machine. These updates just help with one instance of a much
bigger problem and won't magically make your computer (and the software
you run) secure.

Have a look at [1] or uMatrix. These are much better mitigations, IMHO.
But if you are really security concerned you already know that anyway.

Nico

[1] https://noscript.net/

      On 03/20/2018 06:14 PM, Nico Huber wrote:

  These patches
need to be added stat
 You obviously have no idea what you are talking about.
What makes you say that?
  AFAIK, nobody who has the right to submit to the blobs
repository has commented yet on
 newer microcode updates or was asked personally if this is acceptable.
 You might have noticed that microcode updates are not public domain but
 licensed.
Almost every linux distro redistributes them without issue and intel is
suppository a coreboot contributor (to which I have been reminded of
multiple times)

I don't see as to how that is something that can't be worked around by
asking people to download it themselves from a browser or making a shell
script that imports intel's EULA and asks the user to agree to it before
downloading it when they compile coreboot.

Other microcode updates are included coreboot so are a variety of ME
images and other binary blobs from intel so I fail to see the
distinction here.
  - the stakes
are too high for this to take months.
 You still didn't get what Spectre is
about, did you?
I do.
  It's just one of many side-channel attacks that
are possible when you run untrusted code on your machine.
The whole point of a VM is
that you are able to run untrusted code with
some decent level of isolation and spectre ruins this.
What other exploits exist which can easily read data from a VM's host?
If there is a fixable problem why not fix it?

The idea that the only way to go about things is to trust all the code
that runs on your computer is backwards and unrealistic as even if you
only ran foss programs on a modern linux you still have millions of
lines of un-audited code loaded with exploits.
  These updates just help with one instance of a much
bigger problem and won't magically make your computer (and the software you run)
secure.
Yes obviously but this is saying that because you can't be fully secure
you shouldn't bother with anything at all.
  Have a look at [1] or uMatrix. These are much better
mitigations, IMHO.
 But if you are really security concerned you already know that anyway.
That
wasn't the question and I don't appreciate replies like this.
Should firmware programmers be the only ones using coreboot? I have
patched my kernel and various other programs before but I have no reason
to use git and I couldn't figure this out myself.

If you were a sysadmin for a large company would you tell them to not
bother applying the spectre mitigations? should their users use umatrix
instead and that anyone who accidentally enables a site with encryption
key/password stealing malicious javascript gets fired? Enabling
javascript on a per site basis is like playing minesweeper - eventually
you will step on a mine no matter how careful you are.

I have to use javascript for many websites I need which is why I have a
browser in a VM just for them but I don't want them to be able to be
able to read host memory or the memory of other VM's.

[Nico Huber]

      On 21.03.2018 00:03, Taiidan(a)gmx.com wrote:
  On 03/20/2018 06:14 PM, Nico Huber wrote:
 
  These
patches need to be added stat
 You obviously have no idea what you are talking
about.
 What makes you say that?
You. You seem to rate the convenience to have a binary in the blobs
repository higher than possible redistribution issues.

Though, we might have a simple misunderstanding here. I now realized
that you were trying to cherry-pick that commit into a different re-
pository. This thread is about a change to the blobs repository which
is independent of the coreboot source repository and has different
rules.

Anyway, I wasn't telling not to fix it, I was just offended by the way
you want to fix it and your arrogance. You can mitigate Spectre in many
ways. These microcode updates are just part of one way. And putting
them into coreboot is just one way to apply them. And having them in
the blobs repository is just for convenience. Yet, you claimed the lat-
ter must happen.

  AFAIK, nobody
who has the right to submit to the blobs repository has commented yet on
 newer microcode updates or was asked personally if this is acceptable.
 You might have noticed that microcode updates are not public domain but
 licensed.
 Almost every linux distro redistributes them without issue and intel is
 suppository a coreboot contributor (to which I have been reminded of
 multiple times)
The files are explicitly distributed by Intel for Linux distributors, we
are not a Linux distributor. And, FWIW, Intel hasn't ever contributed to
our blobs repository.

  I don't see as to how that is something that
can't be worked around by
 asking people to download it themselves from a browser or making a shell
 script that imports intel's EULA and asks the user to agree to it before
 downloading it when they compile coreboot.
You are already free to add any microcode update to coreboot you want.
And we kind of ask people by prompting during coreboot configuration.
Not every license is an EULA btw.

  
 Other microcode updates are included coreboot so are a variety of ME
 images and other binary blobs from intel so I fail to see the
 distinction here.
Yep, but they were submitted a long time ago. And that stopped at some
point. I don't know yet if due to licensing issues or just because it's
more convenient for Google to maintain their own, hidden blobs repo.

  - the stakes are too high for this to take months.
 You still didn't get what Spectre is about, did you?
 I do.
  It's just one of many side-channel attacks
that are possible when you
 run untrusted code on your machine.
 The whole point of a VM is that you are able
to run untrusted code with
 some decent level of isolation and spectre ruins this.
So does Rowhammer, any caching related side-channel attacks, hyper-
threading related side-channel attacks, I don't know maybe more. These
attacks exist and are possible, some may be more complicated than
Spectre but most of all: They are not as popular as Spectre.

  What other exploits exist which can easily read data
from a VM's host?
Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot
on the code around your VM (no matter the microcode updates in ques-
tion). You can make it secure against Spectre even without these micro-
code updates.

  If you were a sysadmin for a large company would you
tell them to not
 bother applying the spectre mitigations? should their users use umatrix
 instead and that anyone who accidentally enables a site with encryption
 key/password stealing malicious javascript gets fired? Enabling
 javascript on a per site basis is like playing minesweeper - eventually
 you will step on a mine no matter how careful you are.
Good analogy, you are right. No matter how careful you are, you may get
powned at some point. But what you suggest doesn't seem much better,
trigger all mines you can spot all day with a gas mask on that only
protects you against one kind of mines that hasn't been spotted yet in
the wild.

Nico

[Martin Kepplinger]

      Am 21.03.2018 11:13 schrieb Nico Huber:
  On 21.03.2018 00:03, Taiidan(a)gmx.com wrote:
  On 03/20/2018 06:14 PM, Nico Huber wrote:
 
  These
patches need to be added stat
 You obviously have no idea what you are talking
about.
 What makes you say that?
 
 You. You seem to rate the convenience to have a binary in the blobs
 repository higher than possible redistribution issues.
 
 Though, we might have a simple misunderstanding here. I now realized
 that you were trying to cherry-pick that commit into a different re-
 pository. This thread is about a change to the blobs repository which
 is independent of the coreboot source repository and has different
 rules.
 
 Anyway, I wasn't telling not to fix it, I was just offended by the way
 you want to fix it and your arrogance. You can mitigate Spectre in many
 ways. These microcode updates are just part of one way. And putting
 them into coreboot is just one way to apply them. And having them in
 the blobs repository is just for convenience. Yet, you claimed the lat-
 ter must happen.
 
  AFAIK,
nobody who has the right to submit to the blobs repository has 
 commented yet on
 newer microcode updates or was asked personally if this is 
 acceptable.
 You might have noticed that microcode updates are not public domain 
 but
 licensed.
 Almost every linux distro redistributes them without issue and intel 
 is
 suppository a coreboot contributor (to which I have been reminded of
 multiple times)
 
 The files are explicitly distributed by Intel for Linux distributors, 
 we
 are not a Linux distributor. And, FWIW, Intel hasn't ever contributed 
 to
 our blobs repository.
 
  I don't see as to how that is something that
can't be worked around by
 asking people to download it themselves from a browser or making a 
 shell
 script that imports intel's EULA and asks the user to agree to it 
 before
 downloading it when they compile coreboot.
 
 You are already free to add any microcode update to coreboot you want.
 And we kind of ask people by prompting during coreboot configuration.
 Not every license is an EULA btw.
 
  
 Other microcode updates are included coreboot so are a variety of ME
 images and other binary blobs from intel so I fail to see the
 distinction here.
 
 Yep, but they were submitted a long time ago. And that stopped at some
 point. I don't know yet if due to licensing issues or just because it's
 more convenient for Google to maintain their own, hidden blobs repo.
FWIW, my understanding is that Intel *calls* this microcode release 
"Linux".
Nothing in the license text refers to Linux or Linux distributors. In 
principal
it is distributable. The relevant OEM part of the license basically says

* only use with Intel CPUs, only under this license
* don't reverse engineer
* only distribute in conjunction with a "written license aggreement" 
like a
"break-the-seal license" to "safeguard Intel's ownership rights".

That last part may indeed be tricky. Other than that, it may be good to
include the license text in the blobs repo directly.

IANAL, but coreboot might not be compliant indeed now. I can imagine
*some* way of achieving compliance like a prominent statement with
"press any key" during the build process though.

Coreboot should (only) care about *it's* users and pass on this license 
to them
(distributors or whoever, who then can deal with it too).

In short: We can greatly improve the situation quite easily, and 
probably
should do so. Thanks for bringing this up.

  
  - the stakes are too high for this to take months.
 You still didn't get what Spectre is about, did you?
 I do.
  It's just one of many side-channel attacks
that are possible when you
 run untrusted code on your machine.
 The whole point of a VM is that you are able
to run untrusted code 
 with
 some decent level of isolation and spectre ruins this.
 
 So does Rowhammer, any caching related side-channel attacks, hyper-
 threading related side-channel attacks, I don't know maybe more. These
 attacks exist and are possible, some may be more complicated than
 Spectre but most of all: They are not as popular as Spectre.
 
  What other exploits exist which can easily read
data from a VM's host?
 
 Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot
 on the code around your VM (no matter the microcode updates in ques-
 tion). You can make it secure against Spectre even without these micro-
 code updates.
 
  If you were a sysadmin for a large company would
you tell them to not
 bother applying the spectre mitigations? should their users use 
 umatrix
 instead and that anyone who accidentally enables a site with 
 encryption
 key/password stealing malicious javascript gets fired? Enabling
 javascript on a per site basis is like playing minesweeper - 
 eventually
 you will step on a mine no matter how careful you are.
 
 Good analogy, you are right. No matter how careful you are, you may get
 powned at some point. But what you suggest doesn't seem much better,
 trigger all mines you can spot all day with a gas mask on that only
 protects you against one kind of mines that hasn't been spotted yet in
 the wild.
 
 Nico