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

121–130 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#121

Post by cheeseprocedure »

fermienrico wrote: post #38
frazar0 wrote: post #24

Earlier quoted context omitted.

A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...

Thanks. So apparently, my system: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) is unpatched! Is it because of LTS version? Most servers run this including mine.

Ubuntu’s kernel package updates are pending.

This Ubuntu Wiki page is being updated with relevant information and package updates as they become available:

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...

Re: Meltdown and Spectre Linux kernel status

#123

Post by cesarb »

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…

> These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential disclosure.

In this particular case, most of the fix had to be done in the operating system (the new microcode only enabled extra functionality needed by part of the operating system fixes), so it makes sense that operating system developers were allowed (and required) to prepare in advance. The three most relevant operating systems are Windows, OSX, and Linux; for Linux, one of the most important distributors is Red Hat. That gives two of the groups which were notified in advance: hardware (Intel, AMD, ARM) and operating systems (Microsoft, Apple, Red Hat, a few others).

Re: Meltdown and Spectre Linux kernel status

#124

Post by fragmede »

arianvanp wrote: post #97
JdeBP wrote: post #88

Earlier quoted context omitted.

You do not need to read in between the lines to learn that; several commentators have come right out and said it. * http://lists.dragonflybsd.org/pipermail/users/2018-January/3... ( https://news.ycombinator.com/item?id=16084641 ) * https://medium.com/@frankycaron/this-week-in-words-the-langu... ( https://news.ycombinator.com/item?id=16075588 ) * http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... One of t…

If those 4 extra days of embargo would not have caused a total PR disasters on Intel's side will eat my socks. This wouldn't have become any better given another week of time.

The fact that Intel is rumored to have know about this since June lends credence to your belief, however if that week would have let OS vendors have updates ready, and cloud providers already patched, then it would be less of a disaster. There's a certain amount of flailing about when details are released earlier than expected, and vendors don't have a answers or instructions prepared.

Re: Meltdown and Spectre Linux kernel status

#126

Post by alibert »

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…

I finally found the changelog for the patch that Red Hat applied to their kernel: https://git.centos.org/patch/rpms!kernel.git/6202b1a49906b21... (scroll to mid)

I think we can say that Red Hat does have its own implementation for now.

edit : formatting

Re: Meltdown and Spectre Linux kernel status

#127

Post by cesarb »

frazar0 wrote: post #24
fermienrico wrote: post #12

With so much going on - is there a way in linux to know whether my system is patched or not? Similar to the powershell script for Windows?

A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...

> grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!"

That command checks for the "bugs: cpu_insecure" entry in /proc/cpuinfo. However, that line only appears in some of the kernel versions. Recent kernels will have either "cpu_insecure" or "cpu_meltdown" (the name has been changed), while for instance the 3.10 kernel from CentOS 7, which has a backported version of these patches, doesn't even have the "bugs:" field.

And it's that 3.10 kernel which has all the workarounds (both for Spectre and Meltdown), while the more recent kernel has only what's been upstreamed, which so far is only the Meltdown workaround.

It's a mess.

Re: Meltdown and Spectre Linux kernel status

#128

Post by lathiat »

ComputerGuru wrote: post #41

This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.

You need to run dist-upgrade or some other variant that will install new packages to pull in kernel upgrades. The reason is that each new kernel is its own package, depended on by (in the case of Ubuntu for example), the linux-generic package. apt upgrade wont install new packages, dist-upgrade will.

other options include "apt upgrade --with-new-pkgs" or using unattended-upgrades to automatically install them.

Re: Meltdown and Spectre Linux kernel status

#129

Post by smarx007 »

cesarb wrote: post #123
Gracana wrote: post #112

Earlier quoted context omitted.

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…

> These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential disclosure. In this particular case, most of the fix had to be done in the operating system (the new microcode only enabled extra functionality needed by part of the operating system fixes), so it makes sense that operating system developers were allowed (and required) to prepare in advance. Th…

Ubuntu and BSD still have no fixes. It indeed seems like a preferrential disclosure. Plus no 2nd-tier cloud providers like DO were notified.

Re: Meltdown and Spectre Linux kernel status

#130

Post by Xylakant »

keyme wrote: post #119
ahakki wrote: post #109

Earlier quoted context omitted.

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

All that these mitigations did was disable all obvious precise timers. All you need for a new attack is a novel way to create a precise timer. And since it’s now known how valueable such a timer would be, I’m certain that minds more clever than me will take a shot at this.
Post reply on HN