Intel Ships (hopefully Stable) Microcode for Skylake, Kaby Lake, Coffee Lake | Hacker News Reader

Intel Ships (hopefully Stable) Microcode for Skylake, Kaby Lake, Coffee Lake

arstechnica.com

60 pointsrbanffy19 comments

I'm disappointed that Intel is getting all the attention here.

ARM64 chips like A72 have meltdown/spectre issues too. Chips like the ones the current lineup of ARM Chromebooks. Nobody is backporting Meltdown fixes to kernel before 4.16(?)[1], Google isn't updating Chrome OS kernel from 4.4 for these Rockchip devices, and that's because the closed source Mali GPU drivers only work on a fixed kernel version: 4.4. Furthermore, a kernel update isn't sufficient, there needs to be an update to the firmware too.[2] I suspect this means the chromebook must be opened, and a write protect screw will need to be removed to flash a new read only BIOS.

Intel has 32[3] separate class action lawsuits over this issue. AFAIK, nothing is happening to the companies selling broken hardware, with no fix, or plans to fix.

Very disappointed.

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

[2] https://developer.arm.com/support/security-update

[3]https://arstechnica.com/gadgets/2018/02/32-class-action-suit...

>ARM64 chips like A72 have meltdown/spectre issues too.

meltdown/spectre are two different exploits (as much as intel likes to group the two together distribute blame). meltdown only affects intel.

ARM themselves say that Cortex-A75 is affected by Meltdown, check link [2] in OPs post.

> Cortex-A75: Variant 3 (rogue data cache load) - Yes

You are wrong. See [2] above. Variant 3a is meltdown. A proof of concept is here,

https://github.com/lgeek/spec_poc_arm

I've tried it personally. It is vulnerable.

Also, the ARM market is much more fragmented, with hundreds of different implementations. This is an excellent article on why the parts used in the Raspberry Pi series are not vulnerable to Spectre:

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...

Are you certain Chromebooks have a read-only BIOS? They recently shipped firmware updates to fix a widespread TPM vulnerability.[1]

[1] https://www.chromium.org/chromium-os/tpm_firmware_update#TOC...

TPM is not the bios. There is a write protect screw in the motherboard of your chromebook. It must be removed to flash the RO BIOS.

https://www.chromium.org/chromium-os/developer-information-f...

> and that's because the closed source Mali GPU drivers only work on a fixed kernel version: 4.4.

There's an easy fix: add a fourth ChromeOS software channel (currently there's stable, beta and dev) that ships an image without a GPU blob and with a modern kernel.

There are plenty of users willing to disassemble, disable write-protect, flash new firmware and re-enable write-protect.

Inconvenience, and disabling hardware acceleration for video decoding is a small price to pay for security.

Why not both?.gif

https://lwn.net/Articles/738225/

"It was said that everybody within ARM is in favor of solving the problem by open-sourcing ARM's driver — except for one recalcitrant high-level manager."

Now would be a good opportunity to lean on that one person.

Chromebooks can run mainline kernel without GPU now. It's just not ChromeOS. And you have to be able to install Arch Linux. And build/install your own kernel from source. There's just a very small fraction of a percent of ChromeOS users interested or even capable of that.

https://www.chromium.org/chromium-os/how-tos-and-troubleshoo...

Here's the full PDF from Intel, showing the status of microcode updates for what looks like CPUs going back to what looks like the first 64-bit Core CPUs -- https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...

(Disclaimer: I work for Intel, but not on anything related to this and have no knowledge on the topic outside of this PDF)

Intel ships, but only to vendors, while they could ship those damn microcodes directly on their website. We now have to wait for vendors to put those microcodes in their BIOS and release them...

If vendors ever end up releasing them for older motherboards. It doesn’t look like Asus will be doing so for mine, an X99-Deluxe, purchased four years ago.

They release a microcode package for Linux. The kernel will load it from an initramfs, so no need to flash your BIOS. First lines in my dmesg are:

   [    0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16
   [    0.000000] Linux version 4.14.14+ (mattst88@p50-ethernet) (gcc version 6.4.0 (Gentoo 6.4.0-r1 p1.3)) #19 SMP Sun Feb 4 00:20:02 PST 2018

As you can see, your update is outdated (from the 20171117 bundle, pre-Spectre).

It is on thier website.

Not the updated ones. The ones on the site are from November.

This might be a silly questions, but it's not addressed by the article, I don't know the answer, and I suspect I'm not the only one: Is the microcode update likely to help reverse performance degradations that resulted from kernel-level remediations?

No, it adds new branch history controls that let you make things even slower.

What about Broadwell-E chips?

Reply on news.ycombinator.com