Hacker News Reader

Comment by Animats | Hacker News Reader

Stanford's EE 380 had a talk on these vulnerabilities yesterday, from the Red Hat guy working on mitigations. There were some CPU designers in the audience. (Not Hennessey, though.)

The general comments were that Meltdown is a huge and easy to exploit vulnerability. Under Linux, any process can effectively read all of kernel RAM. There are straightforward software and hardware mitigations available. The next generation of CPUs should have that fixed.

Spectre is much harder to exploit and much tougher to fix. It's not an inevitable problem with speculative execution. IBM Z-series mainframes apparently don't have this problem. But it's going to be tough.

The real problem is all that hardware and software out there in the field vulnerable to Meltdown. There will be unpatched systems for years to come. That's what worries the RedHat guy. They have customers wanting patches to old kernels they no longer support.

View on HN

I was also there, and that was _one of the things_ that worried Jon Masters (the guy from Red Hat). In general, there seemed (to me) to be a consensus that as long as you had access to high-resolution timing (like RDTSC), and any form of speculation/prediction (even in in-order pipelines), then you could have exploits.

The recording will eventually be up at https://www.youtube.com/playlist?list=PLoROMvodv4rMWw6rRoeSp..., but I can't recommend it. Unfortunately, Mr. Masters spent most of the ~75 minutes on introductory material (a fairly common mistake at EE380). The best discussion happened in the additional hour after the official end of the talk (and of the recording).

In fact, Pro Tip to people presenting at EE380 (and, for that matter, most "Company X wants to show us Y" meetings that I've attended): Take your slide deck, and delete the first 40% of it.

In early statements, AMD was claiming its processors are immune to Meltdown but vulnerable to some variants of Spectre [1]. Has it now been determined that AMD processors are also vulnerable to the former? (or have the criteria evolved?) I can find statements going either way, but I am not sure if they are precise.

[1] https://developer.amd.com/wp-content/resources/Managing-Spec...

> The real problem is all that hardware and software out there in the field vulnerable to Meltdown. There will be unpatched systems for years to come. That's what worries the RedHat guy. They have customers wanting patches to old kernels they no longer support.

What uses cases involve running new untrusted code on legacy unsupported systems?

> What uses cases involve running new untrusted code on legacy unsupported systems?

Well yes, you shouldn't be doing that (particularly the 'unsupported' bit). The thinking here, I suppose, is that Meltdown makes privilege escalation straightforward once a malicious party has access to the system via another vector.

In my company, we run self-hosted physical servers (i.e. we're the only user on the systems) and debated whether to disable the page table isolation fix since we were seeing about a 30% performance hit.

The decision we took was that we would accept the performance hit since Meltdown means that any unauthorized entry into the system has a privilege escalation path since kernel memory is essentially readable by any process. (Quite an easy and quick decision, really.)

> The thinking here, I suppose, is that Meltdown makes privilege escalation straightforward once a malicious party has access to the system via another vector.

On an unpatched system, that's not likely to be hard in the first place.

Reply on news.ycombinator.com