Slashdot Mirror
When F00F Bug Hit 20 Years Ago, Intel Reacted the Same Way (itwire.com)
troublemaker_23 writes: A little more than 20 years ago, Intel faced a problem with its processors, though it was not as big an issue as compared to the speculative execution bugs that were revealed this week. The 1997 bug, which came to be known as the F00F bug, allowed a malicious person to freeze up Pentium MMX and "classic" Pentium computers. Any Intel Pentium/Pentium MMX could be remotely and anonymously caused to hang, merely by sending it the byte sequence "F0 0F C7 C8". At the time, Intel said it learnt about the bug on 7 November 1997, but a report said that at least two people had indicated on an Intel newsgroup that the company knew about it earlier before. The processor firm confirmed the existence on 10 November. But, says veteran Linux sysadmin Rick Moen, the company's reaction to that bug was quite similar to the way it has reacted to this week's disclosures.
"Intel has a long history of trying to dissemble and misdirect their way out of paying for grave CPU flaws," Moen said in a post to Linux Users of Victoria mailing list. "Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they could be induced to run processory instruction 'F0 0F C7 C8'? "No, of course you don't. That's why Intel gave it the mind-numbingly boring official name 'Pentium Processor Invalid Instruction Erratum', hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire bug'."
"Intel has a long history of trying to dissemble and misdirect their way out of paying for grave CPU flaws," Moen said in a post to Linux Users of Victoria mailing list. "Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they could be induced to run processory instruction 'F0 0F C7 C8'? "No, of course you don't. That's why Intel gave it the mind-numbingly boring official name 'Pentium Processor Invalid Instruction Erratum', hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire bug'."
For real. This has shown that these code monkeys know zero about computer architecture. This isn't a flaw in an implementation, this is a flaw in a fundamental principle of CPU design.
You are absolutely correct here and I completely agree.
I'm worried about this 'AMD is safe' bullshit that's been floating around. No, the Meltdown paper specifically says AMD has the same problem - out of order execution of instructions accessing protected memory - they just couldn't get the side channel to work and suggest it may just need some optimization. That doesn't mean AMD is immune, it just means they haven't gotten it working - yet.
You come close here, but still miss the mark. With Meltdown, there are two components at play: out-of-order execution and observable side-effects in cache. Both Intel and AMD implement out-of-order execution. As you point out, it is a fundamental concept in modern CPU design. The problem is not that out-of-order execution takes place. The problem is that some implementations (namely Intel, and one ARM design) fail to properly protect against access to the discarded data. This could be protected against in the CPU by properly clearing the cache of results from instructions that end up being invalidated or by delaying access to those areas until authorization has been verified. I believe that AMD does the latter. The patches that have been discussed on LKML (the kernel page table isolation, or KPTI) sort of forces the CPU to do the first thing (because putting the kernel memory in a different process/address space forces a context switch, which will wipe caches, registers, etc.). So, AMD's claim that their design is immune to Meltdown is completely believable based on the facts to date. That does not mean that another vulnerability will not be found. It just means that Meltdown specifically exploits a design implementation flaw.
In fact, an AMD engineer submitted a patch to the KPTI patch set that disables KPTI for AMD CPUs. I find it extremely doubtful that, given all the publicity and scrutiny with these vulnerabilities, that AMD would come out on LKML and make a public statement of "nah, this does not apply to us" unless that were actually the case. If they are making that up, then they are committing PR suicide.
Meltdown and Spectre depend on the CPU working as intended, and that's the problem. As the papers point out, everyone has long been focused on CPU performance but we may need to accept giving up some of that performance for more security.
This absolutely correct insofar as Spectre is concerned, but not so much for Metldown.