Martell1977 :
Plus, from what was said by the author of the i3-8100, the patches out there now are hotfixes and the real, complete patches are still in the works. So all the numbers we see now are likely not the final result.
I didn't believe that AMD was totally unaffected, just didn't seem plausible. However, AMD says that they are not affected by one of the vulnerabilities as it exploits one of Intel's design flaws.
According to Linus (and I'll take the mastermind behind Linux and Mac* over any Intel/AMD Rep, and let the rep convince him). the patches are very biased in the way they work, and written to be as debilitating as possible to all parties by Intel. Makes sense as far as driving sales if anything else.
Actually, they apply patches liberally to things they shouldn't, including patching AMD chips for bugs they don't have. Please understand that a bug fix for a security issue on this level is not a bug fix, it's turning off the part of your CPU with the bug and doing it's work in emulation. Intel (who are issuing Spectre/Meltdown bugfixes period) is turning off bits of AMD chips for no reason.
I can tell you now that I know that AMD could not have been affected by the same side channel attacks, because Spectre's SC method relies on prefech/pred 'guessing' sum results or memory addresses and prefetching them before they are 'needed'. Intel was miles ahead of AMD at pred prefetch in the day of the P4 and still is now. The P4 was actually reliant on it because it's pipeline was so long that it would cost several times longer than a K6 to flush buffers after a cache miss. Obv Intel planned for P5 or better steppings to reach the clocks that the core was built to make.
All the way to Sandy, AMD was using bascally the same prefech from Athlon XP/Sempron.
What this does do however, is give Intel the perfect opportunity to make all those people still enjoying Sandy Bridge and 8 core Xeon X's a massive speed bump that might make them upgrade. It's not like CPU's are getting slow every weekend like they used to.
(*because Mac runs on BSD Unix and that's foundationally a Linuxified Unix)
There is no long term bug fix because you have to change the design of the processor. If you accidentally make one part of the Cpu wrong, there is no spare part to work around. Everything else has something to do or it wouldn't be there, and obviously the issue is in the metal and switches not the 1s and 0s. That line was Intel saying that basically Coffee Lake is still as vulnerable as any before as it was not redesigned to eliminate the bug.
Looking at just how long the bug apparently existed, it's possible that the first CPU that Intel design without this bug will be slower than the last CPU with that bug. It has to be at the core of the CPU logic to go through probably 100s of releases, steppings and iterations without being spotted or tripped over, or simply disappear with design updates.
EDIT: Read back and I seem to be making statements that are a little unbelievable so I will update below with links to where this info is from. Italics is Linus verbatim words.
https://techcrunch.com/2018/01/22/linus-torvalds-declares-intel-fix-for-meltdown-spectre-complete-and-utter-garbage/
Meanwhile, a bunch of other things are added in the same patch that Torvalds points out are redundant with existing solutions, for instance adding [performance harming] protections against an exploit already mitigated by Google Project Zero’s “retpoline” technique.
Why do this? Torvalds speculates that a major part of Intel’s technique, in this case “Indirect Branch Restricted Speculation” or IBRS, is so inefficient that to roll it out universally would result in widespread performance hits. So instead, it made the main Meltdown fix optional and added the redundant stuff to make the patch look more comprehensive.
Is Intel really planning on making this shit architectural? Has anybody talked to them and told them they are f*cking insane?
"They do literally insane things. They do things that do not make sense. That makes all your [i.e. Woodhouse’s] arguments questionable and suspicious. The patches do things that are not sane.
…So somebody isn’t telling the truth here. Somebody is pushing complete garbage for unclear reasons. Sorry for having to point that out"
Woodhouse (who in a long-suffering manner asks they “be done with the shouty part”), later in the thread acknowledges Torvalds’ criticism, calling IBRS is “a vile hack” and agreeing that “There’s no good reason for it to be opt-in [which means that OS must choose to turn it on at boot, and current implementations
do not check if the CPU needs the patch or not, and this was written entirely by Intel including that bit].” But he but notes some points that are, if not exactly in favor of Intel’s approach, at least explain it a bit.
Intel, for its part, offered the following statement: “We take the feedback of industry partners seriously. We are actively engaging with the Linux community, including Linus, as we seek to work together on solutions.”