Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

281–290 of 298 posts

Re: Linux page table isolation is not needed on AMD processors

#281
post #252

Would it be possible to slow down segfault notifications to mitigate the attack? For example, if the segfault was not on kernel space, halt the application for the time offset of a kernel read. In this way all segfaults would be reported at more or less the same time and the attack could be avoided. Are there any sane apps that depends on timely segfault handling and thus might be affected by such a workaround?

It's not timing the segfault delivery itself, the idea is to time another read of your own address space after the fault to see if it's been prefetched or not. Maybe you could CLFLUSH on segfault delivery though.

Turns out "maybe" is "not" - if you put the faulting read at a mispredicted branch target, you don't take the fault.

Re: Linux page table isolation is not needed on AMD processors

#282

Earlier quoted context omitted.

Ok you lost me at “future historical fact”. Again that is a fancy way of saying pure speculation. No I don’t know for a fact that the NSA didn’t order Intel to build a buggy ME into all its processors. I can’t prove that it didn’t happen. And maybe your speculation will turn out to be right. I am arguing that my speculation that this was incompetence is significantly more likely to be correct than your speculation of…

Not exactly but almost. I am saying this is the most likely outcome. Judging by other activities of the intelligence agencies and working with pure speculation -- not hiding from these words, you are correct by calling it that -- I still think it's much more likely they commissioned the Intel ME. You mention critical thinking in another comment. Critical thinking, the way I apply it, also requires a historical contex…

OK. And with that you are saying that you are basing this on 95% speculation and 5% pattern recognition with no direct evidence, and yet it's the most likely outcome.

And I am saying that the confidence interval on that calculation is just orders of magnitude not tight enough. I am not denying that you could be right. It's just that I am giving that possibility something like a 1% chance of being true, while something like 85% chance of this being pure incompetence by Intel management and engineers (the rest being some other explanation that's neither malice nor direct incompetence). I don't think you and I can find a common ground on this estimation.

Again though, ME is a bad thing because it's not open source, it can't be turned of, and it's buggy. Regardless of who ordered its creation, it sucks.

Re: Linux page table isolation is not needed on AMD processors

#283

Earlier quoted context omitted.

Yes? Because acting on pure unvarnished unburdened by critical thinking speculation is not a good idea?

Critical thinking would demand recognition of the fact that intelligence agencies compromising security isn't a hypothetical anymore, it's a fact, and it would further demand intense skepticism of unauditable and hostile (resists attempts to disable it) code running below ring 0.

I never said they don't. Simply that in this case there is no evidence, direct or circumstantial, pointing to Intel ME being born out of an order by an intelligence agency. Could it be? Sure. But critical thinking demands facts, not speculation. Facts are:

1. Intelligence agencies have been known to force companies to give them access to their products.

2. Companies have been known to comply, if reluctantly, at least until a whistleblower exposes the program.

3. Intel ME was developed as an on-chip version of an external card that is actually useful.

4. Intel has made poorly engineered products before.

5. Intel isn't in a habit of open sourcing firmware.

6. From a technical standpoint, Intel is fully capable of creating a system that doesn't allow C&C through a bug and an exploit.

7. AMD, the second largest computer chip maker does not have a matching system that can't be disabled and that has similar bugs.

Based on this, I'd say it's possible that the NSA (or equivalent) asked Intel to develop ME and add a bug to allow C&C, but very unlikely.

It's also possible that the NSA (or equivalent) asked Intel to develop ME and add C&C and Intel did it through a deliberate bug, but very unlikely.

It's also possible that Intel tried to develop a feature the market might want, and screwed up the implementation. This seems to me to be very likely. It's the simplest explanation (Occam's razor) and it requires only incompetence, not malice (Hanlan's razor), so it's sort of by default most likely.

If someone can produce an iota of evidence to the contrary I will change my allocation of probabilities appropriately, but so far the evidence is "it could have been done" and "they've been known to spy on people in the past". In my book that's not a strong enough argument.

Re: Linux page table isolation is not needed on AMD processors

#284
post #6

Earlier quoted context omitted.

I think the du case was an outlier. Normal workloads shouldn't be so heavily affected. I am expecting a few percent loss on most programs though. It's basically a larger penalty for making a syscall, which was already a fairly slow operation so performance minded people avoid them in tight loops. It will be bad for people who need to do lots of fast I/O I suspect.

Sounds like servers handling lots of small UDP packets would be hit pretty hard.

Anyone run any DNS server benchmarks, esp BIND and PowerDNS?

Re: Linux page table isolation is not needed on AMD processors

#285

Earlier quoted context omitted.

For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.

Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).

I wouldn't be so sure about that. Linus and Gross might think that it could be microcode fixable, because they wanted it configurable. Opt-out. However in the current patchset it's mandatory.

With a future os-specific microcode patch a config option would make more sense. They just need to find a 2nd C3 register to seperate user from kernel space or do the permission check before prefetches. Like AMD does. On Linux this check would be cheap, on Windows NT not.

Re: Linux page table isolation is not needed on AMD processors

#286
post #90

Earlier quoted context omitted.

Until more information is available, who knows. It might be fixable in microcode, it might be fixable in a new processor stepping, it might require a deeper rework that wont come out until the next generation of processors (or even the generation after that).

Though if it were going to be fixed in microcode, it seems like this would have played out by Intel just having released new microcode already and encouraged people to update to it, rather than every OS vendor scrambling to rewrite large chunks of their memory management, you know?

Yes, but they might have focused more on Windows, which is not so easy to fix. Esp in microcode. The NT kernel fixes were already out for months, there the table layout is not as simple as in Linux, whilst Linux is still discussing it. For Linux microcode you just need to look at the first bit for a permission check. Not so with Windows.

Re: Linux page table isolation is not needed on AMD processors

#287

This is going to have dramatic effect on the cloud computing market. It might make sense to make sure any VMs you run are on AMD processors or it can really hurt your performance and basically cost you more to do the same workload. It also seems, from early benchmarks, this can slaughter performance with databases.

I wonder if cloud providers will ask Intel for partial refunds when their CPUs get 5% to 30% slower than promised?

Why? They pass it on to customers. More interesting if Google or Facebook will react. They could need up to a data centre each to compensate for that (I assume both have very syscall heavy applications). Maybe not suing Intel but pouring more money into the development of competing chips

Re: Linux page table isolation is not needed on AMD processors

#288

Earlier quoted context omitted.

If the hit is as bad as they say (30% performance), cloud providers will be almost forced to upgrade when the new hardware comes out that fixes it. Are they really ready to adopt AMD? Go long on INTC?

I'm not sure AMD could even handle the volume...

I'm sure they'll be happy to produce 24/7 or raise some prices to take care of that.

Re: Linux page table isolation is not needed on AMD processors

#290

Earlier quoted context omitted.

What chip exactly introduced this feature? Core 2 architecture? Nehalem?

> It is understood the bug is present in modern Intel processors produced in the past decade. Source: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...

Arstechnica says it could be any processor since 1995.

https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

Post reply on HN