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'."

Comments

Re:"Why Intel gave it the mind-numbingly boring na

[El Cubano]

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:

• If you made a mistake, make it look like your enemy/competitor/associate actually made the mistake.
• If you can't shift the blame entirely to your enemy/competitor/associate, at least make them appear equally responsible.
• If you can't even shift the blame partially to your enemy/competitor/associate, at least make it appear you did nothing that was actually wrong. (Bonus if you can make the thing you did wrong look like something you did right.)
• If you did something right, you are the only one who had anything to do with it.
• If your enemy/competitor/associate did something right, you were actually the one who did something right.
• If you can't make it look entirely like you were the one who actually did something right, then at least make it appear that you had equal part with your enemy/competitor/associate in whatever they did right.

This is what companies, organizations, political parties, and countries do.

Differences of Intel's most famous 3 problems

[Junta]

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.

Re:What about the rest of them?

[thegreatbob]

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.

Re: "Why Intel gave it the mind-numbingly boring n

[El Cubano]

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.