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

161–170 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#161

Post by Tuna-Fish »

Xylakant wrote: post #96
rolux wrote: post #67

Earlier quoted context omitted.

Keeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235

Also: if you don’t have high precision timers, you probably could also go and increase the number of guesses to cancel out noise. After all, this is a statistical side channel attack. This will be fun for quite some time.

Doing that is harder than usual, because the time before rollback is very limited, reducing the amount of cache lines you can pull into the cache and you can measure a given cache line only once.

The attack is already pretty damn slow (1kB/s) in C, if you have to collect a statistically significant sample in JS it might well slow down enough to not really work properly.

Re: Meltdown and Spectre Linux kernel status

#162

Post by jancsika »

JdeBP wrote: post #79
_nalply wrote: post #69

From my cursory reading I understand it is a cleverly orchestrated timing attack. In other words, if something would need 500 picoseconds you have bit 1, if it is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air). This is made possible because processors execute the read speculatively even if it is actually forbidden. This read causes a cache hit. Of course the read is never brought into effect bec…

Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions. * https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... ( https://news.ycom…

> One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing.

But to read the data one still must use timing attacks, no?

Re: Meltdown and Spectre Linux kernel status

#163

Post by gphreak »

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.04 will be based on 4.15 which doesn't make sense to me.

Debian stable maybe?

EDIT: I know I can install updated kernels but I'd rather stick with what a core distribution provides if possible

Re: Meltdown and Spectre Linux kernel status

#164

Post by CuriousCosmic »

fizixer wrote: post #62
bonzini wrote: post #52

Earlier quoted context omitted.

It's closer to the second, but: 1) the vulnerability is local, not directly tied to spreading as malware (but these days placing JavaScript in an ad is easier and possibly more effective than a virus...) 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter.

> 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter. You're missing the point. Not doubting the smartness of black hats, white hats likely took their time to discover the flaw. If you make the details public in a controlled manner and then announce the fixes shortly after, you essentiall…

unfortunately the fixes are in an open source project so even if all they knew was that there was a CPU level exploit and that specific code fixed it, black hats would still have a weaponised exploit before most people had patched their systems.

Re: Meltdown and Spectre Linux kernel status

#165

Post by blockoperation »

blockoperation wrote: post #142

What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. The 20171215 update carried by some distros only seems to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed, are they covered by the 20171117 update, or are the new microcodes simply not ready for all models yet? Of cours…

Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes.

I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]).

[1] https://patchwork.kernel.org/patch/10147547/

Re: Meltdown and Spectre Linux kernel status

#166

Post by BuckRogers »

jcastro wrote: post #8
Changu wrote: post #3

If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. I use Linux Mint and have not seen any recent kernel updates. Which kernel version is considered safe?

> 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 scale, Ubuntu or bust.

Re: Meltdown and Spectre Linux kernel status

#167

Post by erikb »

pas wrote: post #143
erikb wrote: post #136

Earlier quoted context omitted.

Insider trading happens all the time. But usually you don't read about it in the news. So that the Intel CEO's insider trading got him in trouble shows there's someone fighting against him. Thus, no that's not the full story. I know it's hard to accept but the official scape goat is rarely the trouble maker. Or do you believe that the 2008 crisis was just the doing of that one banker that got jailed?

The 2008 crisis was an emergent systemic risk. (Similar to Spectre) But Meltdown is Intel's fuckup, and the insider trading is on Krzanich. And naturally anyone is happy to point that out, even if they sort of fucked up by implementing speculative execution and thus allowed Spectre on their platform. Or it can be simply someone that noticed this unusual sale, and saw the circumstances ripe for a bit of naked shorting…

Right. Shorting is also an option. Haven't thought about it. It would also be insider trading, though, and it's not in the news that someone shorted Intel stock big time.

Re: Meltdown and Spectre Linux kernel status

#168

Post by kazinator »

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 problem is that the kernel/user protection is just a sham that is not being taken seriously by the CPU implementation. It allows access to take place without a proper mode change. Basically the whole fetch-decode-execute machinery (all of its pipelines, caches, registers and other areeas) should be regarded as untrusted and prevented from accessing or storing anything unauthorized according to the current security state of the CPU.

Re: Meltdown and Spectre Linux kernel status

#169

Post by kashyapc »

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.

I should have used the term 'coordinated disclosure', which probably reflects reality more. The links (with remarks from tptacek) pointed out by JdeBP (thanks) up-thread are a useful read.

Re: Meltdown and Spectre Linux kernel status

#170

Post by gkya »

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…

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).
Post reply on HN