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

171–180 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#171

Post by kasabali »

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.

apt's kernel update process is not broken, you've just somewhat borked your system either by removing the kernel meta package or messing with repository sources/priorities.

Make sure "linux-image-amd64" package is installed for Debian (and whatever equivalent package name for Ubuntu) and "apt upgrade" will install new kernel packages just fine.

(And this is actually not even needed for most kernel updates in Debian because most of the time package name stays same and updated in place, package name is only changed if ABI is changed and requires recompilation of DKMS modules)

Re: Meltdown and Spectre Linux kernel status

#172

Post by kasabali »

lathiat wrote: post #128
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.

--with-new-pkgs is already the default for apt, thus a plain apt upgrade indeed installs new packages.

Re: Meltdown and Spectre Linux kernel status

#173

Post by pkilgore »

codys wrote: post #78

> As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually I'm looking forward to that story.

I'll eat my hat if it isn't some version of "here is a giant patch set we never worked through the chain nor asked about at all please make it your problem to mainline it immediately, followed by, well, a good old fashioned LKML go fsck yourself."

Re: Meltdown and Spectre Linux kernel status

#174

Post by wolf550e »

tedunangst wrote: post #102
tptacek wrote: post #93

Earlier quoted context omitted.

No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.

In theory it should be possible for a hyper visor to retrofit a fix into a guest, but it's messy and I doubt anyone will ever do it. Could be fun though. Quick sketch: disable EPT and go back to shadow paging. Maintain a third page table with any kernel pages unmapped. Invisibly swap between on syscalls.

This sounds really slow to me. What is the overhead of "disable EPT and go back to shadow paging", or what was the performance win of EPT?

Re: Meltdown and Spectre Linux kernel status

#175

Post by lima »

amluto wrote: post #132

One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences. 1. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x8…

As far as I can tell, the RHEL/CentOS kernel has mitigations not only for Meltdown but also Spectre (using the new MSRs).

Am I right in assuming that Red Hat built their own mitigations, independently from upstream?

Re: Meltdown and Spectre Linux kernel status

#176

Post by amluto »

lima wrote: post #175
amluto wrote: post #132

One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences. 1. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x8…

As far as I can tell, the RHEL/CentOS kernel has mitigations not only for Meltdown but also Spectre (using the new MSRs). Am I right in assuming that Red Hat built their own mitigations, independently from upstream?

It seems like a smallish consortium of poorly coordinated developers built the Spectre mitigation patches. Upstream wasn't involved until a couple days ago.

Re: Meltdown and Spectre Linux kernel status

#177

Post by DSMan195276 »

agumonkey wrote: post #159
DSMan195276 wrote: post #85

Earlier quoted context omitted.

Yes, you understand it correctly. The bug is really just that cache hits that are caused by speculative execution do not get invalidated. This is technically a bit of a speed-up, but it leaves information behind about the speculative execution that took place. It is also worth understanding the differences between Spectre and Meltdown, since they are distinct. Spectre refers to reading process memory via measuring ca…

so the perf hit comes from a mandatory cache invalidation instruction added by the patch ?

No. That would be the ideal situation, but it is not possible to make the CPU do that just from a microcode update, it would require new hardware. So we're left with creating other ways to get around it via software. The perf hit comes from those software fixes.

Meltdown is the most expensive perf wise, but more straight forward to fix. Processes can only access addresses mapped in their address space, so if you in unmap the kernel while a user process is running then they can't read it. This is expensive because every syscall now flushes the TLB due to changing the page table, so page accesses are in general slower.

Spectre is more complicated to fix. One part of the fix is the retpoline hack that basically attempts to defeat the branch predictor through clever code. It looks like the CPUs are also getting microcode update to allow it to disable the branch predictor in some situations.

Re: Meltdown and Spectre Linux kernel status

#178

Post by dustinkirkland »

gphreak wrote: post #163

Based on the remarks I'm wondering if there's a distribution out there that is similar to Ubuntu LTS but only uses LTS kernels. I'm on CentOS right now and love it, but from what I've understand so far it would be preferable to be on a newer kernel. I was planning to look at Ubuntu LTS and while they do have updated kernels available they seem to ignore LTS: https://wiki.ubuntu.com/Kernel/LTSEnablementStack Also, 18.…

Actually, Ubuntu created the term "LTS" in 2006, for Long Term Support releases. Greg started using the term himself just a couple of years ago.

Re: Meltdown and Spectre Linux kernel status

#179

Post by isostatic »

gkya wrote: post #170
macdice wrote: post #140

Earlier quoted context omitted.

It will be pretty unfortunate if it turns out that the projects that maintain a kernel (FreeBSD, various others) only received notification at Christmas, while various Linux distros (who have to deal with packaging, release, QA but not developing their own kernel patch since that comes from upstream) got a long warning period. It seems that way... Looking forward to reading about how this played out when the dust set…

There was a post to OpenBSD- tech list telling no BSDs were told anything. And a blog post from Canonical says that the patch will be available 9th January (IIRC).

OpenBSD didn't respect the embargo a few months ago with the wifi issue, no surprise that they weren't told about this up front.

Re: Meltdown and Spectre Linux kernel status

#180

Post by smarx007 »

macdice wrote: post #140
smarx007 wrote: post #129

Earlier quoted context omitted.

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

It will be pretty unfortunate if it turns out that the projects that maintain a kernel (FreeBSD, various others) only received notification at Christmas, while various Linux distros (who have to deal with packaging, release, QA but not developing their own kernel patch since that comes from upstream) got a long warning period. It seems that way... Looking forward to reading about how this played out when the dust set…

Yep, FreeBSD got notified a week before Christmas: https://www.freebsd.org/news/newsflash.html#event20180104:01

The Spectre mitigation is expected soon but there is no ETA on Meltdown yet: https://www.reddit.com/r/freebsd/comments/7och5a/freebsd_was...

As others say, OpenBSD indeed violated embargoes a few times.

Post reply on HN