For Now At Least AMD CPUs Are Also Reported As "Insecure"

[wizard69]

I think some of you guys are completely off your rockers here. The rational thing to do eith problems like this is to find a work around that solves the issue at hand globally and yhen work on a fix for the exceptions. Im sure that if AMD and even Intel CPUs are found to be free of this problem code will be added to revert operation.

As for AMD and Ryzen the latest kernel from RedhatRawhide wouldnt even boot on my Ryzen mobile systrm. I have no idea why but it could be due to this work or something else. Mind you couldnt even bring the kernel up in a VM.

At this point i wouldnt be surprised if Linus stops with the RC releases and takes the kernel back into development mode for a few weeks. After all the work around is a major hack that will need to be tested.

[Holograph]

I think some of you guys are completely off your rockers here. The rational thing to do eith problems like this is to find a work around that solves the issue at hand globally and yhen work on a fix for the exceptions. Im sure that if AMD and even Intel CPUs are found to be free of this problem code will be added to revert operation.

Ridiculous. The issue is Intel until it's shown otherwise (seriously, you can't just assume that other hardware has specific bugs!). There is literally only risk in enabling extra security code for applications where it's unnecessary - especially when rolling it out quickly, testing be damned (which really is the Linux way in general). You talk about "globally" like it's common sense that all X86 CPUs are the same, when they aren't. It's an instruction set and not an architecture. You might as well enable this "feature" for ARM and other instruction sets; would barely be a bigger jump than it is to enable for AMD. Intel's problems are the world's problems!

Linus should take the kernel back into development for several weeks, yes, but that's true of every single kernel release. The first several releases in a kernel series should be considered (by end users) as the RC. And the "RCs" should be considered beta at best.

[Flaburgan]

It all depends of your point of view. If you really care about security, it seems fare to enable PTI for everyone until a PoC is available. I see a lot of people here saying only Intel is affected although as far as I know no example of code has been published. On another topic, even if enabled only for Intel CPU, this patch will drastically impact electricity usage worldwide... Not good for the planet.

[Holograph]

It all depends of your point of view. If you really care about security, it seems fare to enable PTI for everyone until a PoC is available. I see a lot of people here saying only Intel is affected although as far as I know no example of code has been published. On another topic, even if enabled only for Intel CPU, this patch will drastically impact electricity usage worldwide... Not good for the planet.

If you really care about security, guess you should disable all caches completely then.

Enjoy your 1990s performance.

But seriously, it doesn't increase security to just do random stupid stuff without a reason. And adding additional layers of complexity only increases the odds of other bugs in your code causing issues. Your argument of "if you really care about security" might as well be extended to the act of using a computer at all. If you really want to be secure, better not.

Arguments should be based on evidence, not fear of the unknown.

[bridgman]

Why none of your developers are participating in the discussion at lkml and tells this Intel/Linux developer to disable the 'feature' on AMD hardware?

Do you mean "other than Tom Lendacky" ? Tom is an architect in the CPU software group.

It all depends of your point of view. If you really care about security, it seems fare to enable PTI for everyone until a PoC is available. I see a lot of people here saying only Intel is affected although as far as I know no example of code has been published.

What do you mean by "Proof of Concept" here ? AFAIK the difference between behaviour of Intel and AMD CPUs is documented in their respective micro-architectural specs, not in code.

[sa666666]

Look, whatever else is said, and however fanboi's on both sides try to spin this, the facts are facts, and this is what they are so far:

• The fix is required for Intel CPUs, not AMD ones.
• Applying the fix to AMD CPUs (where not needed) is slowing them down for no good reason.

Whatever else happens in the future is irrelevant right now. Intel needs the fix and has to suffer a slowdown, AMD doesn't. End of story. If Intel CPUs are improved in the future, the patch can be removed/improved. If AMD CPUs are found to also need a fix (and associated slowdown) in the future, it can be done then. I see no reason whatsoever to impact AMD CPUs by what is, right now, by definition an Intel issue.

I know there's probably politics involved, and Intel probably doesn't want it widely known that AMD doesn't have similar problems. But AMD shouldn't suffer for this. Ryzen also went through a buggy phase for the past 6 months (CPUs needed to be RMA'ed, needing to use 'rcu_nocbs', etc). At that time, Intel users didn't have to suffer slowdowns or adverse effects because of Ryzen issues.

AMD had their issues and are now starting to resolve them. They took their lumps and dealt with it; now it's Intel's turn.

[pmorph]

You don't seem to have much faith in kernel developers
I'm no kernel developer either, but since there's a clean fix I'm pretty sure the AMD patch (or some variation of it) will accepted before dust settles.

[sa666666]

I have faith in most developers, particularly when they dealing only with matters of logic. But it is foolish to think that at least some developers don't have motives other than purely logical ones. I think calling attention to such issues helps keep everyone honest, particularly those developers that work for some specific corporation and don't necessarily care if their patches affect other, competing corporations.

Note that this doesn't just apply to Intel vs. AMD; it can be true of any set of corporations. The kernel should give the best performance, where possible, in all configurations. And IMHO, a patch should NEVER adversely affect something that it is not related to. That is the definition of a regression.

IMO, I don't think the patch from Intel was meant to cause harm to AMD. But it worked out that way, and it should be fixed.

[monraaf]

Please continue to monitor and act in this story, do not allow _them_ to bury this patch!

You should take off your tinfoil head. The message of your friend is just childish and every reasonable developer will just ignore it.

No one is going to bury this patch. It has been delayed until it has been verified which CPUs are actually affected.

Also, anyone with such a patched kernel can just pass "pti=off" on the kernel command line to disable the feature.

[michaelb1]

You should take off your tinfoil head. The message of your friend is just childish and every reasonable developer will just ignore it.

No one is going to bury this patch. It has been delayed until it has been verified which CPUs are actually affected

This "tinfoil head" is called a common sense! Before we raised the dust,
this 2-line patch from AMD developer has been ignored at LKML for 1 week !
But now, after we let _them_ know the people are watching, finally there is some action:
https://www.phoronix.com/scan.php?pa...isable-x86-PTI
And don't claim it's just a _coincidence_ , because it is not

Also, anyone with such a patched kernel can just pass "pti=off" on the kernel command line to disable the feature

The majority of Linux users, especially the newbies, will keep forgetting about this option and enjoying their pointlessly slow performance at AMD. How beautiful