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.
Linux page table isolation is not needed on AMD processors
281–290 of 298 posts
Re: Linux page table isolation is not needed on AMD processors
#282Earlier 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…
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
#283Earlier 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.
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
#284Earlier 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.
Re: Linux page table isolation is not needed on AMD processors
#285Earlier 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).
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
#286Earlier 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?
Re: Linux page table isolation is not needed on AMD processors
#287This 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?
Re: Linux page table isolation is not needed on AMD processors
#288Earlier 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...
Re: Linux page table isolation is not needed on AMD processors
#289Re: Linux page table isolation is not needed on AMD processors
#290Earlier 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...
https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...