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

[Spacefish]

Guy's playing with fire. If the two things appear to be connected, this would be insider trading.

Well let´s observe the fallout of the Bug, if it affects the stock a lot, then i would write to the SEC to investigate the sale and they may punish him for insider trading...

[michaelb1]

I think one should assume AMD knows its architecture better than the Linux Kernel developers outside of AMD's own and that the flaw is an Intel problem. Intel doesn't want that to be so because it will bury them in all sorts of legal crap, on top of lost contracts for new hardware purchases.

It has to be accepted by Intel (Intel has a big amount of people working as kernel developers and maintainers.)

They will not be able to avoid this, of course. They will have to accept the patch. They'll probably just bitch about it for a while first, probably saying it's not a proper patch. They might try to delay the patch just enough for benchmarkers all over the world to post the results first, so that Intel CPUs are suddenly not slower than AMD ones.

Thank you very much! Your posts has motivated my friend to subscribe to linux-kernel mailing list
just to write this message:

https://lkml.org/lkml/2018/1/3/179

Why this wonderful tiny patch by Tom Lendacky is still not merged? If
it is just Intel who made these insecure CPUs , for which this "slowdown workaround" is required, --- why the AMD CPU owners should suffer from Intel's design faults ? " cpu_insecure " is Intel's problem ; according to Tom Lendacky from AMD - AMD CPUs do not need this "slowdown workaround" which is required for Intel CPUs. Please merge this patch as soon as possible

Of course, the Intel employees would be happy to see this patch get delayed or even not merged, because its a shame and bad reputation for their company and products :

" I would rather not just hard-code it in a way that we say one vendor has never and will never be affected " --- by Dave Hansen from Intel corporation

Luckily, according to LKML - a message with Tom's patch is the Top Hottest Message viewed ! The fate of this patch is being closely monitored by the people all over the world, and hopefully the Linux community will not allow any injustice to happen

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

To subscribe to linux-kernel mailing list, send a plain text message
subscribe linux-kernel
to
[email protected]

Then, follow the majordomo's instructions to confirm the subscription
by sending
auth XXXXXXXX subscribe linux-kernel [email protected]
where XXXXXXXX is a special code from a letter with instructions

Finally, send your message to [email protected]

[ddriver]

That linux maintainer who "assumed" that all x86 cpus are affected needs to be thoroughly investigated. AMD specifically stated that they are not affected, and even bothered to explain why.

Crippling amd performance without the need to can only be interpreted as a handout to intel. I don't see any good reason for anyone to do so aside from a generous payoff. This is CRIMINAL.

"I don't understand how anyone can claim that AMD's cpu's are unaffected:"

They are affected by the UNNECESSARY crippling of the performance. It is unnecessary because amd cpus are not affected by the flaw and don't require the performance crippling workaround.

[Inopia]

Thank you very much! Your posts has motivated my friend to subscribe to linux-kernel mailing list
just to write this message:

https://lkml.org/lkml/2018/1/3/179

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

He has a point in that there are technically other x86 manufacturers besides Intel and AMD. They should just list the affected Intel processor generations and enable it for them instead of enabling it for non-AMD. Future Intel generations are not likely to be vulnerable either so using vendor string isn't really an optimal solution. There's plenty of release candidates left so it shouldn't be too much.

The AMD commit seems more like a sick burn than the best way to enumerate buggy CPUs affected.

[Guest]

That linux maintainer who "assumed" that all x86 cpus are affected needs to be thoroughly investigated. AMD specifically stated that they are not affected, and even bothered to explain why.

Crippling amd performance without the need to can only be interpreted as a handout to intel. I don't see any good reason for anyone to do so aside from a generous payoff. This is CRIMINAL.

"I don't understand how anyone can claim that AMD's cpu's are unaffected:"

They are affected by the UNNECESSARY crippling of the performance. It is unnecessary because amd cpus are not affected by the flaw and don't require the performance crippling workaround.

It will be stupid to cripple AMD hardware on Linux. Especially if Windows and *BSD won't do the same. If they do it's nothing, but damn politics and anti-AMD propaganda.

[michaelb1]

He has a point in that there are technically other x86 manufacturers besides Intel and AMD. They should just list the affected Intel processor generations and enable it for them instead of enabling it for non-AMD. Future Intel generations are not likely to be vulnerable either so using vendor string isn't really an optimal solution

Perhaps a better patch would follow someday, but - for a current moment of time - it is better to disable the "unneccessary slowdown" for AMD CPUs, rather than not disabling it. It is Intel problem, so its' the Intel employees who will have to write a follow up patch that will also disable a slowdown for some of their unaffected generations. The current handling of a problem (simply ignoring this patch from AMD guy) is unacceptable

[ddriver]

Amd short alter that patch. Although I guess it is not up to them what goes in. The linux foundation is all about money. And intel happens to give it more money than amd.

[sykobee]

Clearly the final kernel release will need to isolate the 'fix' to Intel's affected CPUs only, unless the user demands the feature to be applied on non-Intel CPUs. I would assume that there is a proof-of-vulnerability that will be run on many systems to find out which ones are not-susceptible. It may be that VIA/Zhaoxin CPUs are also not affected, so the code would change to simply identify Intel CPUs are affected, and limit the mandatory fix to them only.

If it doesn't, then at some level there is a defamatory effect on AMD's products.

Assuming Intel found out about this midway through last year, then the complete hardware fix will not be available for a couple of years, at least. Luckily for Intel they have a partial solution in more recent CPUs that limits the performance drop.

[ddriver]

Assuming Intel found out about this midway through last year, then the complete hardware fix will not be available for a couple of years, at least. Luckily for Intel they have a partial solution in more recent CPUs that limits the performance drop.

If they put it as first priority, they can release fixed product line in 6 months. For their biggest money makers they could cut it down to 3 months, but it will cost them extra to hurry it that much.

[newwen]

If they put it as first priority, they can release fixed product line in 6 months. For their biggest money makers they could cut it down to 3 months, but it will cost them extra to hurry it that much.

I have no doubt that they will fix it shortly in product revisions, at least for the Xeons. I’d like to know if the redesign will impact slightly single thread performance.
The biggest problem for intel is the huge impact on their image from customers. It could even force them to accept product replacements as it happened with the pentium FDIV fiasco.