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'."
This isn't the 0.9998356st time they've done this?
The "point" is that Intel, Microsoft, and many large 'technical' corporations are apparently more concerned with marketing than technical prowess. Consider that Intel spends more on marketing each year than AMDs entire R&D budget.
Maybe if they spent half the time, energy and money on technical stuff as they do on slimy marketing, this issue wouldn't have happened in the first place.
I'm not sure I understand the point of this article.
I agree. This article is not news. Not because it is about something that happened 20 years ago, but because it is a rehash of standard PR spin and maneuvering:
This is what companies, organizations, political parties, and countries do.
'merely by sending it the byte sequence "F0 0F C7 C8".' Ã am pretty sure that it wasn't enough to "send" the byte sequence. That assumes that you could trigger the bug remotely. Instead you would need to execute that code sequence, so you need permissions to install software. Still bad, but not a huge deal 20 years ago, when computers with Intel CPUs were almost always single-user machines.
Despite the constant negative PR
0xC0FEFE
The Meltdown bug is much much worse. It essentially means you cannot use Intel in the Cloud. This is why their stock lost $11 billion so far and why the CEO sold all his stock earlier.
Of course there's already another vulnerability out in the newer processors.
Otherwise NSA wouldn't have allowed this bug to go public.
"Trump!!", the new Godwin.
The Pentium FDIV bug:
No sane way to workaround at all, and no way to work around it in real mode operating systems, which mattered a lot at the time. Intel ultimately forced to do a recall because they could not provide accurate results for applications. Three models (60, 66, and 90mhz) exposed and caught *relatively* early and volumes were manageable.
F00F bug:
Feasible OS workarounds for protected mode operating systems with no performance impact. Real mode operating systems still mattered, but if you were running real mode there were tons of other ways to freeze the whole system so F00F wasn't that interesting in real mode anyway. Workarounds looked *ugly*, but they were cheap. Intel screwed up, but software workaround was pretty appropriate.
Meltdown:
There are workarounds, but could be very expensive. At the same time, they have two decades of exposed products and much higher volumes than they had before. So the scope of a recall would be way more massive. The workaround results in reduced performance, not incorrect results. If anything were to happen, I'd bet some sort of small rebate or credit for the performance loss, and telling the world to just deal with the performance impact if they care about security.
XML is like violence. If it doesn't solve the problem, use more.
Spectre (speculative execution bug) affects them all, Meltdown (memory privilege check dodging) does not appear to affect non-Intel processors, but that could always change. The the vilification, at least from my perspective, stems more from their denialist (it's working as intended, hyuk!) attitude towards the thing.
There is no XUL, only WebExtensions...
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.
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.
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.
Consider that Intel spends more on marketing each year than AMDs entire R&D budget.
That's because Intel is a FAR larger company than AMD. Intel spends more money on marketing than AMDs entire REVENUE. AMD had revenues last year around $4.27 billion and Intel revenues were around $59.4 billion. The companies aren't even close to being peers. AMD spends a similar percentage of revenues on marketing but they simply aren't anywhere near as big. That doesn't mean AMD cares less about marketing - it just means they don't have as much cash to spend.
The "point" is that Intel, Microsoft, and many large 'technical' corporations are apparently more concerned with marketing than technical prowess
Software companies are different animals than hardware manufacturers. Every software company on the planet spends more on sales and marketing than on engineering and R&D. That's not a commentary on the relative important of those functions but rather just what they cost to perform those activities. Selling software is less able to achieve economies of scale in most cases. Look at the financial statements of Microsoft, Apple, Google, Oracle, and you'll see that around 10-30% of their costs are to actually design the products. SG&A (Sales and Marketing) typically is about double that amount or more. Intel has a lot more R&D costs because they have a lot of very expensive plants and tangible equipment to fund. Software R&D doesn't generally require building expensive hardware prototypes and research into novel applications of physics.
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.