Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meltdown and Spectre Linux kernel status

kroah.com

Post reply on HN
Print view View original

111–120 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#111

Post by JdeBP »

erikb wrote: post #105
davidw wrote: post #50

Reading between the lines, it seems this is a pretty colossal fuckup by Intel; both in terms of the bug but especially how it was handled.

Reading between the lines would be figuring out who at or around Intel profits from this chaos. There is certainly someone, but since everybody is just focussed on the technical issues, whoever it is will probably throw a party this weekend.

No, one does not need to read in between the lines for that, either. One can simply read the lines. Far from everyone being "just focussed on the technical issues", the questions over the share dealings have made the news in the papers, from The Australian to The Irish Times.

Re: Meltdown and Spectre Linux kernel status

#112

Post by Gracana »

kashyapc wrote: post #107
alibert wrote: post #87

FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…

There's such a thing called: 'embargo period', wherein CVEs are (in most cases) responsibly disclosed to various parties---including several Linux distributions---much ahead than the general public, to coordinate security errata. So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course). As to whether Red Hat has kernel developers…

I really dislike the term "responsible disclosure" in this context. I might consider it responsible to notify a software vendor about a vulnerability in their software so they have a chance to issue a fix to their customers before the rest of the world finds out. But this situation is different. These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential disclosure.

Re: Meltdown and Spectre Linux kernel status

#113

Post by wilun »

_wmd wrote: post #82
JdeBP wrote: post #64

Earlier quoted context omitted.

The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…

AFAIK on Intel it's not possible to load a microcode update over the top of one already loaded by your firmware, so if the firmware shipped an older update, the firmware really needs to be updated. (Please someone correct me if this isn't the case -- I can't even remember where I read this)

I don't think this is correct at all. I've personally seen the contrary happening.

EDIT: however for some rare features, it is preferable to have them loaded by the firmware. I don't know if this is the case here.

Re: Meltdown and Spectre Linux kernel status

#114

Post by wilun »

JdeBP wrote: post #64
Santosh83 wrote: post #36

What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this…

The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…

The microcode updates can typically be stored and loaded by the motherboard fw, though, and some OSes don't even load their own version.

Re: Meltdown and Spectre Linux kernel status

#115

Post by JdeBP »

Gracana wrote: post #112
kashyapc wrote: post #107

Earlier quoted context omitted.

There's such a thing called: 'embargo period', wherein CVEs are (in most cases) responsibly disclosed to various parties---including several Linux distributions---much ahead than the general public, to coordinate security errata. So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course). As to whether Red Hat has kernel developers…

I really dislike the term "responsible disclosure" in this context. I might consider it responsible to notify a software vendor about a vulnerability in their software so they have a chance to issue a fix to their customers before the rest of the world finds out. But this situation is different. These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential…

The Register had some quite pointed remarks on the use of the word "responsible" by Intel in its press releases.

* http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...

See also these:

* https://news.ycombinator.com/item?id=14010010

* https://news.ycombinator.com/item?id=16043952

Re: Meltdown and Spectre Linux kernel status

#116

Post by newman314 »

davidjade wrote: post #86
JdeBP wrote: post #64

Earlier quoted context omitted.

The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…

Windows, at least for right now, does not seem to be updating CPU microcode during boot. If you run the PowerShell Get-SpeculationControl script that gives you the status of the updates it states that the CVE-2017-5715 fix requires hardware support. If you don't have it you are told to get a BIOS update from your OEM. WIthout it, the status for CVE-2017-5715 is listed as not enabled due to missing hardware support. O…

This appears to be my experience too. I'm checking a few VMs and they are showing as missing hw support.

Do note that Microsoft appears to have updated their doc in the last day or so. They are now saying that three registry settings need to be set (instead of 2 previously).

  reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
  reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
  reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f
Some quick Googling seems to indicate that Windows has the ability to update microcode.

http://forum.notebookreview.com/threads/how-to-update-microc...

Maybe this will happen with a later update from Microsoft as I'm doubtful that BIOS updates will happen with at least one of my systems.

Re: Meltdown and Spectre Linux kernel status

#118

Post by tyrust »

dorfsmay wrote: post #17
rand0mthought wrote: post #5

Earlier quoted context omitted.

So, there is NO kernel update available for Ubuntu 16.04 at this time.

They will be available on 2018/01/09: "Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible." https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-th...

The status of patches can be viewed at the CVE pages listed at https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...

Re: Meltdown and Spectre Linux kernel status

#119

Post by keyme »

ahakki wrote: post #109
Xylakant wrote: post #33

Earlier quoted context omitted.

Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.

> JavaScript […] is a demonstrated attack vector Does that mean that we are soon going to be vulnerable to remote exploits via WASM as well? Do mitigation attempts such as reducing the JavaScript timing resolution aslo apply to WASM?

They do apply to WASM. However, these mitigations are hardly air tight. I'd expect new exploits anyways.

Re: Meltdown and Spectre Linux kernel status

#120

Post by bonzini »

wilun wrote: post #110
kashyapc wrote: post #107

Earlier quoted context omitted.

There's such a thing called: 'embargo period', wherein CVEs are (in most cases) responsibly disclosed to various parties---including several Linux distributions---much ahead than the general public, to coordinate security errata. So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course). As to whether Red Hat has kernel developers…

It's now called coordinated disclosure, for reasons. And, correct me if I'm wrong, but apparently calling Linus Torvalds and Greg KH the general public (as far as Spectre and its (poor for now) mitigations are concerned) is the new norm. I'm not sure of what the community will think of that. And of the corporate actors involved in that curious choice.

Again, I am pretty sure that they were disclosed the details. This however is very different from being able to commit patches on the day of the disclosure. For one, neither Linus nor Greg are actually writing the code.

The problem here was that discussion was confined within company barriers (with small occasional exceptions) until last Wednesday. Linux thrives because it is based on reaching consensus among all stakeholders, and not being able to discuss the approach to take with respect to Spectre directly resulted in chaos.

I am very happy with the work that we at Red Hat did on this project (though of course not perfect in any way!) and I am proud that our articles are published openly and are being widely shared among the Linux user community at large. However, I certainly would have preferred to work together with all other vendors on a common solution before. But unfortunately, even if (as is the case with Red Hat) upper management is extremely supportive of upstream collaboration, you do what you can.

Post reply on HN