Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

251–260 of 298 posts

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

#251

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.

Why are people insisting this affects cloud computing market? I am not sure if this bug is absolutely limited to cloud instances.

Because this bug allegedly affects hypervisors/VMs.

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

#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.

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

#253

Essentially looks like Intel compromised (whether intentional or not is a different point) the design to get the speed boost that gave them the lead over AMD for the past decade. Will be interesting to see how all this plays out.

> Essentially looks like Intel compromised (whether intentional or not is a different point) If it wasn't intentional, then it wasn't a compromise. So it's not a different point.

"To compromise" means "to weaken" or "to endanger", not "to make _a_ compromise". To make a compromise is an intentional act, but you can compromise (e.g. the security of) something by sloppiness. So yes, it is a different point.

(Yeah, I know, don't blame me. English _is_ weird.)

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

#254

Earlier quoted context omitted.

Is it? Again, that a big claim to make in five words and drop the mic. Can you cite anything to back it up?

How can you request a citation about things relating to possible intelligence agencies efforts with a straight face? It's literally their job to make sure such material doesn't exist or sees the light of day if it does. It's not exactly publicly-funded science now, is it? You request a proof that's impossible to procure. Are you now gonna claim the lack of this proof supports your thesis?

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

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

#256

Earlier quoted context omitted.

Here is some more context - http://pythonsweetness.tumblr.com/post/169166980422/the-myst... The connection between the linked article in this comment and the linked page for this post is that there is a potentially huge bug that will be made public soon and it just affects Intel processors, not AMD - hence the large sale of stock by the Intel CEO.

Not sure if it makes any sense and even logical to compare the market before and after Intel's floating point bug was uncovered a decade ago. My bet is this current bug won't shake Intel's stock price much.

If the workaround being deployed now causes a 30% performance hit in real world usage, even just for some cases, it could hit Intel way harder than fdiv.

A lot of people on Intel will suddenly lose a noticeable amount of performance. Conversely, if your Intel based VMs lose 25% performance, you are now booting up and paying for 20% more VMs for the same load.

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

#257

Earlier quoted context omitted.

I think they have an incompetent management department that decided that no open sourcing ME is a good idea. Marketing is may also be incompetent at picking up the pieces after the bugs were discovered. > 95% speculation. The last 5% comes from exercising basic pattern recognition. No, it's all speculation because pattern recognition is not evidence, as applied here. Like, is it possible that I am an NSA agent trying…

You say "do you have proof?". But nobody can have proof beforehand . That's how these things always go -- something is done under cover and later (usually much later) somebody uncovers it and shows it to the world. Why do you ask of a proof that can't possibly be in the spotlight right now? Many historical facts have been denied and met with skepticism and mockery until they have been proven to be indeed facts. Why i…

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 conspiracy.

Your theory in the above comment is that the NSA or equivalent ordered Intel to build a C&C mechanism into their processors. Intel then did a perfect job covering up this request, but did a piss poor job of implementing it due to incompetence and has not managed to correct it for 10 years. There is no indication that this might be the case but because of other unsavory activities by the NSA or equivalent it can be assumed that at some point evidence will be uncovered that you are right and therefore we should accept it as fact. Do I have that right?

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

#258
post #8

All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...

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?

They could get AMD hardware that works today. We don't know when Intel will have working hardware. It will be at least months and possibly years. Processor design is a long process.

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

#259
post #126

Earlier quoted context omitted.

AMD's triple core processors were quads with disabled cores. Often times processors within a line are processors with manually set lower clock multipliers or disabled cache. Sounds like Intel has just made it unlockable instead of permanent. It just brings to the fore what was already being done, and makes us question again the ethics of pricing models.

Nvidia‘s GeForce cards could be converted to Quadro cards by opening a chip and adding some lines with a pencil. Don’t think that this still works, but a colleague of my father did it for his home PC.

No, that was just spoofing the PCI VID:PID to the kernel. It did not enable hardware features, just fooled the driver into thinking it was another device. You could do the same with a patched kernel if you don't want to solder.

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

#260
Data structures stored in kernel space, such as llds [1], will not incur the overhead of the TLB flush/load.

I suspect that storing data in the kernel space in order to avoid maintaining a large application PD will become the norm, whereas in the past it has been reserved for use cases like search engines with massive in-memory trees.

[1] https://github.com/johnj/llds

Post reply on HN