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

181–186 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#181

Post by gphreak »

dustinkirkland wrote: post #178
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-reading my post it does sound a bit confusing.

What I meant is: Ubuntu LTS seems to not give a damn if the kernel they use is also an LTS release.

Examples would be: 14.04, 16.04 HWE kernels, 18.04 (currently planned to be 4.15).

Re: Meltdown and Spectre Linux kernel status

#182

Post by dingo_bat »

kazinator wrote: post #168

I've been thinking about some of this. A possible design to prevent some of these issues would be to read all protected memory, in speculative execution paths, as dummy all-zero bits value, and not put anything into the cache. I.e. no actual access takes place to any protected area and no breadcrumbs are left in any CPU storage such as a cache. (Then if that path is actually taken, generate the exception). The whole…

The kernel/user enforcement by the CPU is a sham (kinda) in Intel CPUs when the data you want to access is in L1 (people are guessing). This is only for the meltdown issue.

Spectre doesn't care about kernel/user at all. So even other CPUs are susceptible. Every CPU that speculates is vulnerable in theory.

Re: Meltdown and Spectre Linux kernel status

#183

Post by cyann »

newman314 wrote: post #116
davidjade wrote: post #86

Earlier quoted context omitted.

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…

MinVmVersionForCpuBasedMitigations is for VM/Hyper-V: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...

Re: Meltdown and Spectre Linux kernel status

#184

Post by yemich »

BuckRogers wrote: post #166
jcastro wrote: post #8

Earlier quoted context omitted.

> I use Linux Mint and have not seen any recent kernel updates. If you're not aware Linux Mint turns off kernel security updates _off_, you need to check by hand.

I always preferred Mint for desktop Linux. I knew they had a poor security record due to their HTTP downloads at one time, but no kernel security updates is news to me. If you must use desktop Linux, I guess I'll be recommending Ubuntu from now on. In my testing Mint and Ubuntu both work pretty well out of the box on lots of different hardware configurations unlike other distros. But learning this really tips the sca…

A great advantage of linux is allowing the end user choice of distribution and desktop environment to find their specific needs. Unfortunately, not all choices are good. I wish Mint would go away.

Re: Meltdown and Spectre Linux kernel status

#185

Post by pqh »

mjevans wrote: post #98
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…

If you're running a Windows machine, I've no idea how it handles the microcode updates. For LINUX (and probably BSD/etc users): https://wiki.archlinux.org/index.php/microcode#Enabling_Inte... Your distribution probably has a firmware package that has this bootloader stub. It applies the latest microcode updates just before your OS actually begins starting up (but for Linux after the Kernel has initialized things and…

I downloaded the microcode updates from Intel, but hesitate to apply them because one of the expected directories does not exist on Manjaro, so I'm out of my element on how supported the update would be. Do you happen to know if in general microcode updates are distributed in packages? It seems that's probably the case, and if so, I'm fine waiting.

Re: Meltdown and Spectre Linux kernel status

#186

Post by unixsurfer »

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?

The patches on RedHat 7.4 have impact on performance and capacity for a Load Balancer type of workload, see https://www.spinics.net/lists/stable/msg209193.html
Post reply on HN