Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

Post reply on HN
Print view View original

151–160 of 298 posts

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

#151

Post by SolarNet »

anonacct37 wrote: post #2

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?

Yes. AMD didn't take shortcuts, and implemented the spec correctly. Intel took shortcuts, introduced bugs, and now to compensate for that the OS has to work around it in software, it's going to be slow. For years Intel has reaped the benefits of shortcuts for performance, while AMD has been implementing things correctly; now there is a correction.

That's how the market works.

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

#152

Post by yarg »

unethical_ban wrote: post #100
brians wrote: post #52

Earlier quoted context omitted.

IIRC, this fall’s i9 chips and the motherboards supporting them have software-unlockable features. You can literally buy more PCI lanes. Which is another way of saying you had those lanes, and Intel wanted more money before letting you use what you’d already bought.

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.

This is generally the result of segregating defective parts of the chip in order to create a stable (albeit less powerful) chip.

Some of the chips will be fully capable of running with all parts enabled, but in a higher power envelope (this is a guess - but I believe that the fully capable chips most likely to be sacrificed are those that have trouble fitting in the ideal power envelope).

I would also imagine that (under some circumstances) chips that are fully functional within the expected power envelope will be artificially limited in order to control levels of stock.

The vast majority of chips that are limited in this way will be out of spec, unstable or inoperable when unlocked.

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

#153

Post by [deleted] »

amckenna wrote: post #150
calt wrote: post #145

Earlier quoted context omitted.

What's the connection?

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.

[deleted]

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

#154

Post by lvs »

amckenna wrote: post #150
calt wrote: post #145

Earlier quoted context omitted.

What's the connection?

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.

If your allegation is true, that would seem to be very illegal.

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

#155

Post by IgorPartola »

zrm wrote: post #128
IgorPartola wrote: post #67

Earlier quoted context omitted.

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…

> For a large enterprise, monoculture that works is actually better than diversification. But that's the problem. Nothing works 100% of the time, which is why monoculture is bad. When there is a bug that affects 20% of your systems, you can continue operating at 80% capacity, which at a reasonable level of reserve/redundancy means you're still entirely up. With a monoculture the bug affects everything and you're enti…

> This is why hardware abstraction is a thing.

This is the mistake in your argument. Motherboards, CPUs, RAM chips, GPUs are analog and physical objects. For AWS to switch a DC from one mobo to another just to find out that this one draws 5% more power and their standard backup generator can't handle it, which now starts a chain reaction of upgrades is going to incur real world costs. Costs that can't be amortized by writing some code to make the motherboards look the same.

This is basically the A/B testing/one-armed bandit problem. How much do you spend time exploring alternatives vs how much time to you reap the benefits of the fact that all your hardware is exactly the same and best of breed, as based on your testing?

> When there is a bug that affects 20% of your systems, you can continue operating at 80% capacity, which at a reasonable level of reserve/redundancy means you're still entirely up. With a monoculture the bug affects everything and you're entirely down.

These situations simply don't lose enough money to make up for the gains of a monoculture.

Think about it this way. You probably run or at least know someone who runs SaaS products. Do you/they use five different cloud providers in equal measure to make sure you have diversity if one has an issue? Do you/they use five different software stacks in case there is a remote exploit for RoR and PHP holds things up? Do you/they buy groceries at five different grocery stores in case one of them has an e. coli outbreak that the other four don't? The answer to all that is now, because no matter how you try to abstract these things, there is a meaningful difference between PHP vs Django vs RoR vs Express vs .NET and between AWS and GC and Azure, that it would cost you a lot more, not just in billing but in engineering effort to support.

Another example: chances are you've at some point built a RAID array. Did you put different size and performance drives from different manufacturers into it or did you buy N of the same drive type to ensure even performance? If so, why?

Put another way, how much more are you willing to pay on your AWS bill to ensure they are running a mix of ARM, AMD, PowerPC, and Intel chips? Because my guess is that it won't be in the range of 1-2%.

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

#157

Post by daenney »

djsumdog wrote: post #102
nine_k wrote: post #87

Earlier quoted context omitted.

I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)

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

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

#158

Post by daenney »

spiznnx wrote: post #45
airesQ wrote: post #38

Given Intel's dominance of the server market does this mean that datacenter computational capacity will see an overnight ~5% drop? Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?

Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

> Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

It doesn't speed up AMD hardware. Intel incurs a performance penalty (so it doesn't leave Intel the same as before), but that penalty doesn't make your AMD CPU magically go faster.

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

#159

Post by cloakandswagger »

rdtsc wrote: post #24
bitwind wrote: 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...

> I would say this could be an indicator to short INTC and long AMD... I would say that too if I'd be waiting for everyone to sell so then I could buy INTC :-)

Options are much better for playing these short-term, news related swings. This has the potential of being a good one, as INTC is at the peak of a bull run and this news doesn't seem to have hit mainstream sources yet.

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

#160

Post by IgorPartola »

Sir_Substance wrote: post #136
IgorPartola wrote: post #129

Earlier quoted context omitted.

OK, but that's (a) 100% speculation and (b) fails Hanlon's razor. I don't like the fact that you can't disable ME, that it's not open source, and that it's vulnerable any more than anyone else. But this does seem like hyperbole much more than fact.

>OK, but that's (a) 100% speculation 95% speculation. The last 5% comes from exercising basic pattern recognition. I remind you that we're probably talking about interference from the organization that arranged this: https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... The existence of that program was pure speculation, until it turned out to be totally real. >(b) fails Hanlon's razor. This is completely i…

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 to persuade you that you are safe and shouldn't worry about ME? Of course it's possible. But do you have any evidence of that? No.

"Well, in the past the NSA has asked big companies for backdoors into their products" is a true statement with evidence. "That implies that in this case there is a 5% chance that is exactly what's happening" is 100% speculation because again there is no evidence. If you can find any, I am all ears because honestly I am not a fan of Intel, Intel ME, the NSA, government spying, big corporations taking advantage of consumers, or a number of other things I imagine you and I agree on. But I think I am being rational when I say that chances are this is a stupid bug or number of bugs, plus bad old school thinking on the part of the management team, and not a deliberate NSA feature.

Here is my bit of speculation: if the NSA asked Intel to include a backdoor, wouldn't they both have done a better job of creating it? Why introduce a bug when you can include whatever code you want in a closed source firmware? You can literally add any kind of C&C mechanism you want because nobody can see what you are doing and nobody would ever know. Is the NSA that stupid to to ask for a bug that can be found and exploited? Is Intel not able to offer a better technical solution? Wouldn't it be to both of their benefits to do this right from the start? Also, why only approach Intel and not AMD? AMD is not as popular but surely has enough market share to warrant spying on.

Post reply on HN