Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

71–80 of 298 posts

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

#71

Earlier quoted context omitted.

All the more reason to keep JS off by default... ...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate. You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses t…

Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.

there's a subset of the web that still remains a hypertext document database (the 'web 1.0' if you will) instead of becoming an application delivery platform (web 2.0, i hear it's almost out of beta). going JS-less on wikipedia is possible and not at all a bad experience.

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

#72

Earlier quoted context omitted.

I think it will because it shows the downside of a monoculture. Hence big purchasers of CPUs will want to diversify. Also good for ARM vendors I suppose. Disclosure : bought AMD this morning before headlines saying "Buy AMD, short INTC" appeared.

Has there ever been a precedent for this? When there were major bugs in Intel CPU's (or drives, or RAM, or motherboards) did the likes of Amazon and Google invest in diversification? And has it affected stock prices meaningfully? My guess is that they'll see this as just another one off issue that can be fixed with software, then move on. For a large enterprise, monoculture that works is actually better than diversif…

I checked the stock of Intel during the FDIV bug (1994/1995) where they had to go as far as recalling the affected processors at a cost of $500M in January 1995 and there was basically zero effect. By the end of 1995 the stock had actually pretty much doubled in value..

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

#73
post #36

At the meta level this is just a special case of "complexity is evil" in security. CPUs have been getting more and more complex, and the relationship between complexity and bugs (of all types) is exponential. Each new CPU feature exponentially increases the likelihood of errata. A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software…

Wasn't this the idea behind Microsoft's Singularity project?

https://en.wikipedia.org/wiki/Singularity_%28operating_syste...

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

#74

Earlier quoted context omitted.

AMD has their own ME equivalent in their recent CPUs.

ME is actually a gasp useful feature. The problem is with Intel's implementation of it: it's not open source, it can't be disabled, and it's buggy. Fix all three of those, and Intel's stock will go up.

Do you really think enough people care about the ME / control of hardware in general / hardware that spies on you or is out of your control to influence the stock price of a company the size of Intel?

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

#75
post #6

This feels like a big FU to Intel. I've heard this patch can slow down programs like du by 50%. Does that mean AMD is going to find itself running twice as fast as competitors?

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

#76

Earlier quoted context omitted.

Short INTC maybe but I am not sure this means that AMD will increase in value over the long run as a result of this one incident.

I think it will because it shows the downside of a monoculture. Hence big purchasers of CPUs will want to diversify. Also good for ARM vendors I suppose. Disclosure : bought AMD this morning before headlines saying "Buy AMD, short INTC" appeared.

Why would this cause you to diversify? Long-term negative effects of a monoculture are not evenly distributed to purchasers. In fact, if you ran both AMD and Intel CPUs, you'd see application performance differences solely based on processor architecture. This makes application deployment planning way harder. At any given time, there's one CPU that should be purchased, and artificially introducing two "so they don't fail the same way" is bad, specifically because they won't fail the same way.

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

#77

Earlier quoted context omitted.

What about this combined with the Intel ME stuff? I could see large cloud providers starting to at least think about switching to AMD

Large cloud providers don't make decisions emotionally. They'll take a "let's mitigate the ME stuff and buy best support + performance per dollar hardware possible" approach. They don't care much about the opinion of the outraged hackers.

Security track record is taken seriously by many big vendors.

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

#78

Earlier quoted context omitted.

Are you sure that all Intel CPUs are affected? Might just be older ones.

The kernel code changes target all Intel.

Yep, and until the embargo about this is over, we won't know anything with any certainty. This has been one hell of a fun thing to watch from the outside. I run a small test your code service (for all versions of Perl) that could be affected by this so I'm really curious what the whole thing is.

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

#79
post #74

Earlier quoted context omitted.

ME is actually a gasp useful feature. The problem is with Intel's implementation of it: it's not open source, it can't be disabled, and it's buggy. Fix all three of those, and Intel's stock will go up.

Do you really think enough people care about the ME / control of hardware in general / hardware that spies on you or is out of your control to influence the stock price of a company the size of Intel?

No. That's exactly what I'm saying. Most people don't care. Enterprise users do care because ME is useful for them. It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness. They'll see this as a small problem that should be fixed and will ask Intel to do so. Intel will fix it, most everyone will move on. I don't think ME will take down Intel stock, and neither will this page isolation bug.

Intel's value is 99% engineering + manufacturing ability + customer relations. It would be a poor CEO indeed who'd direct their IT to start buying AMD because of this alone.

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

#80
post #77

Earlier quoted context omitted.

Large cloud providers don't make decisions emotionally. They'll take a "let's mitigate the ME stuff and buy best support + performance per dollar hardware possible" approach. They don't care much about the opinion of the outraged hackers.

Security track record is taken seriously by many big vendors.

Is it? That seems like a big broad claim. Again, after things like RowHammer, did anyone actually do anything differently in a way that affected stock prices?
Post reply on HN