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?
What was Intel supposed to call the bug? "The Pentium sucks and can be remotely disabled erratum?"
Continuing:
Moen, who is based in California, said that at the time, Intel's "judo-move response" was to create an information page claiming it dealt with the bug by linking to each of the various x86 OS vendors' bug-fix pages.
Again, what alternative did Intel have? It couldn't patch existing chips so it directed customers to patches provided by OS vendors.
I'm not sure I understand the point of this article.
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.
I'm pissed at them too - where is my slashdot article?
'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
I don't see how marketing plays into it - are you saying the presence of any errata means they are marketing-focused rather than engineering-focused? What exactly is Intel guilty of in the article? Using less provocative titles for their chip bugs than what the media came up with?
Is this a bug in Intel hardware or processor design?
No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
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.
I love how everyone seems to be vilifying Intel when AMD and ARM have the same issues.
Piet Hein!
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.
"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"
You apparently have no goddamned clue about technical stuff. One of the flaws itself lies directly in how Out Of Order Execution is SUPPOSED to work.
Try taking hardware design classes before opening your mouth on a subject you clearly do not know!
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
It's true that AMD isn't affected by Meltdown
According to the AC. AMD, on the other hand, says they are indeed affected.
That's Spectre, not Meltdown. Meltdown is far more egregious, and carries the huge performance penalty.
Both AMD and Intel routinely put out addendums detailing bugs on their CPUs and chipsets. These are normally addressed at BIOS or OS level.
This is different though. Meltdown and Spectre are a result of how branch prediction works on pretty much all modern CPUs and are difficult - if not impossible - to shield from on existing hardware.
" .. but a report said that at least two people had indicated on an Intel newsgroup that the company knew about it earlier before[SIC]..."
But the company is not a monolith, with a single brain that is aware of all the reports from all the employees. Some parts of the company knew about the bug earlier. Other parts of the company who should have acted to fix it and disclose it did not do the right thing.
If we blame wholesale "Intel" then Intel will close ranks and perps will enjoy some amount of protection.
The same thing happens when we generally blame "Police Brutality" or "Islamic terrorism". If we choose terms that allows the organization to blame a few bad apples and maintain some dignity, and we improve the general reaction to make sure the blamed ones are the real "bad apples" and not some scapegoat, over the long run things would improve. For example we should say something like, "Sunni Terrorism" that will allow Shias not feel blamed, or even better "Wahhabi terrorism" to allow other Sunnis to distance themselves from the perps.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
AMD has released a "disable" feature for their ME-analogue. The motherboard BIOS has to support it though, and who the f_ knows if it actually works. I think we need to go back to dipper switches and jumpers so we can physically disable parts of the system.
Early pentiums had a bug in floating point division that would occasionally return a close-but-wrong answer.
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Anyone have a clue?
To have a right to do a thing is not at all the same as to be right in doing it
I've tried this exploit code on Win10 with full updates in FF+Chrome+IE, and on LineageOS 14.1-something on FF+Chrome+stock browser. All just give the output "0".
"When information is power, privacy is freedom" - Jah-Wren Ryel
Does your friend know anything about technology, how complex it is, how easy it is to get something wrong, how hard it is to track the issue down, and how many times a customer claims their problem is the vendors fault when it is really a bug in the clients implementation? Because anyone who is incensed over this, including yourself, certainly doesn't.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
That's Spectre, not Meltdown. Meltdown is far more egregious, and carries the huge performance penalty.
If you say so. I'm no expert on this stuff. The writeup on Hacker News certainly makes Spectre appear to be serious and difficult to mitigate:
The second problem, Spectre (paper), is not easy to patch and will haunt people for quite some time since this issue requires changes to processor architecture in order to fully mitigate.
Spectre attack breaks the isolation between different applications, allowing the attacker-controlled program to trick error-free programs into leaking their secrets by forcing them into accessing arbitrary portions of its memory, which can then be read through a side channel.
Spectre attacks can be used to leak information from the kernel to user programs, as well as from virtualization hypervisors to guest systems.
“In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.” the paper explains.
“KAISER patch, which has been widely applied as a mitigation to the Meltdown attack, does not protect against Spectre.”
The paper they reference is an interesting read (particularly section 8, "Conclusions and Future Work"), available as PDF here.
If you make a living selling really complex stuff, then saying "aw shucks, we did not understand the technology we are producing" is not the way to enhance your sales. Meltdown and Spectre are the result a pile of very basic design errors all joined up.
Sure it can take a team of people with expensive, specialised equipment to debug a CPU, but have a look at Intel's turnover before you come out with this twaddle. If someone says "it looks like there is a problem" then they should be in line for bug bounties, like from software people.
It is our job as /. contributors, geeks and nerds to make the market heap this on Intel till it really hurts, or it will go on happening. Its not like Joe Sixpack call tell fake news when he laps it up.
Sent from my ASR33 using ASCII
"Still bad, but not a huge deal 20 years ago, when computers with Intel CPUs were almost always single-user machines."
20 years ago was 1998, not 1968, and Linux and WinNT were both online as servers back then so your comment is nonsense. Are you a Millenial by any chance? If you are then an FYI - the modern world didn't start when you were born.
How many CPU architectures did Intel release in the past 20 years WITHOUT security defects?
How many did you release?
Give me a break and come back when you run a 5000+ headcount development and engineering organization for two decades.
Not seeing the point of the article is a problem.
REALLY?
Not all companies automatically do the worst thing possible. The fact that intel has a history of twisting and shouting to avoid accepting responsibility for a problem (including trying to minimize it), and avoid replacing faulty products, is a problem. It's news worthy.
Even if it's just for consumers to look at and say "well hey, maybe I should give AMD a chance". But all the better if this is fuel for a class action lawsuit, or larger market forces at work. Maybe this spurs a big player like Amazon or Google to think twice about how much they are willing to bet on Intel hardware.
This cynical "Uh well everybody does it" attitude is false, useless, and if anything encourages apathy.
merely by sending it the byte sequence "F0 0F C7 C8"
Sending, really? What, down a modem, via email, on a webpage?
No, you have to get the computer to execute that byte sequence. That involves a bit more than "sending."
systemd is Roko's Basilisk.
This is what's is objectionable about Intel's behavior
"He ended up having to "prove" to Intel that he was doing things correctly and that their chip was doing math wrong, and before he got a replacement CPU he had to sign an NDA. After doing all of that over the course of weeks/months he finally got a new chip--and then a week or two after that Intel publicly admitted to the fuck up and replaced everyone's chip for free"
Having to prove he was doing things right is perfectly fine but making a customer who has just given you a big heads up on a huge fuck-up on your part wait months? And gagging him with an NDA?
That's assholery.
Pain is merely failure leaving the body
I agree. That's certainly how they'd handle a recall in a "worst case" scenario. They're not going to offer to give you brand new CPUs in exchange for obsolete ones over 5 years old. Heck, they can argue that if you used it that long, you fully got your money's worth out of it, regardless of the current issue.
It'll be interesting to see how this plays out. But I wouldn't be surprised if we wind up with a "mixed" situation, where server class Xeon processors, primarily used in Enterprise cloud environments, qualify for replacement under some kind of exchange program -- while they conclude software patches are sufficient for desktop processors.
Who knows? Maybe this will prompt some of Intel's customers to move in other directions and super real innovation in CPU design and development. Everything that's happened to CPUs in the past 20 years has been a serious of mundane, incremental improvements. Intel has had a stranglehold on the industry and as a result o giant innovations have occurred. It would be interesting to see larger companies like Apple or HP fab their own CPUs. OTOH, its probably convenient for them to be able to blame it on Intel and get discounts on future purchases.
Suppose you were an idiot. And suppose you were a member of congress. But then I repeat myself. -- Mark Twain
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.
It looks like we are even at this point :)
I don't know if I can do those things. I do know that I can tell the truth about something I did and I offer to fix problems that I cause without trying to BS my way around the problem. It isn't about building a CPU - it''s about honesty and morals.
A Narcissist's Prayer
That didn't happen.
And if it did, it wasn't that bad.
And if it was, that's not a big deal.
And if it is, that's not my fault.
And if it was, I didn't mean it.
And if I did...
You deserved it.
It was called f00f because that was the actual machine code for the illegal instruction.
GP goes in a valid direction. But it's not exactly marketing that's been put ahead of security, it's performance. Marketing knows customers care much more about performance than safety. And are the customers wrong? Idiots, for not taking security more seriously?
Think about the security vulnerability inherent in the C library function, malloc. It can give its process access to discarded but unerased data from whatever process last used whatever region of memory the OS hands it, unless steps are taken. They knew what to do about it: wipe the memory. Maybe the OS should do that, or the hardware. But everyone realized it would be a performance hit, even if it was hardware based, and no one wanted that. Instead, the burden was put on the previous process to erase its data before freeing the memory. Library functions such as secmalloc can assist with that, of course. And that was a fairly sensible move. Only erase the data if it is sensitive, otherwise, who cares?
In the design of C, performance was chosen over security and safety pretty much every time. It should be no surprise that hardware design shows the same focus. And it's not wrong. It's safer to drive on slow roads, never exceed 50kph, but people do not want that, they want to go over 100kph, for the good reason that time is also valuable.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I agree. That's certainly how they'd handle a recall in a "worst case" scenario. They're not going to offer to give you brand new CPUs in exchange for obsolete ones over 5 years old.
"Obsolete" is very subjective.
e.g. I have an intel i7-3930K, 6-core with hyperthreading. It's from Q4 2011, and now labeled as EOL by Intel.
However, despite the age still performs neck-on-neck with the Intel I7-7700K 4.2GHz, released on Q1 2017. (cpubenchmark.net Passmark score of the I7-3930K = 12,025, I7-7700K=12,087)
I'm not sure I understand the point of this article.
Condolences. But if you ponder long and hard, you might spot the pattern
Rick Moen
rick@linuxmafia.com
Assholery and "how things work" are not mutually exclusive. Ask any of the #MeToo complainants.
Pain is merely failure leaving the body
No. But I remember the one 1996.987390689
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Keep crying. I'm sure businesses will start taking risks that could cost them billions if you whine loud enough.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
If there is one person whose opinion I'm concerned with it's an AC that makes blatantly false claims, and starts their sentences with "man", man. Thanks for the laugh little stalker coward.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Sure ... but the same argument ALWAYS gets made with older technology. I used to work for a manufacturing business that would never let go of some of their high speed 132 column dot-matrix line printers. Everyone who saw them cried, "Ancient tech! Obsolete! Get rid of it!" But the reality was, I.T. staff weren't clueless. They tried to "upgrade" those many times before, but discovered reasons it was better to keep the status quo. (Among other things, the company relied on multi-part forms because there was a whole procedure in place where a driver received a certain colored copy of the form while one was filed in the office, and another went to the customer as a receipt. I believe a fourth copy was used in-house by other people picking or handling the order. When one of these printers was switched with a laser printer, you had to rewrite the software to print 4 copies of each page AND to print some sort of easy-to-see header to identify who it was intended for - since it wasn't going to be printing on 4 different colored sheets of paper. Papers got lost in the shuffle since they weren't on continuous, tear-off type forms anymore. Page formatting errors were struggled with since the laser didn't always print on pages quite the way the line printers did. And they even lost the advantage they had before where someone could write a quick note in pen on the top of a multi-part form and have it transferred to the other 3 sheets by default.)
Newer isn't always better, and often? Even when it is, it brings a lot of extra problems to solve or unexpected issues. Still - from the manufacturer's viewpoint, "obsolete" is pretty much defined as a product they haven't sold in a few years or more. At the 5 year mark, you probably have no more warranty coverage, even if you purchased one of those "3 year extended warranties". In most accounting circles, owning the hardware that long means they depreciated it to 0 value. And ultimately - you can't argue that you didn't get some decent use out of a product like a CPU that's been in service for 5 full years. At that point, it was your fault for making a poor initial purchasing decision if you didn't ....
Actually I don't like aluminum foil, but I need it to stop the voices in my head...
"Trump!!", the new Godwin.
You may very well be correct that Meltdown doesn't apply to AMD, but my concern is everyone's level of certainty about that isn't grounded in anything concrete at this point, at least nothing I've been able to find. The actual Meltdown research paper said it may still be possible with more effort and I don't recall anything saying they were immune, so it seems to me the certainty behind this claim is based entirely on trust in AMD's word. They may have a very good reason for their claim, but unless I see an actual explanation from them as to why, I can't help but have some doubt about what's going on inside that black box.
The problem is not that out-of-order execution takes place.
I think this is where we disagree since I'd argue it is the problem - letting an attacker execute their own instructions with protected data is the leak, the side channel is secondary. While the implementations discussed in the papers did use a specific cache side channel attack, they also mentioned using other methods that didn't depend on the cache. A channel could be as little as 1 bit of detectable state information that persists after the roll back. Even out of band signals like temperature or EM field could potentially be used. Depending solely on this roll back to be air tight just seems crazy to me.
Honestly, until a given CPU with OoOE can be demonstrated to not do this, I can't help but consider it susceptible to Meltdown and think it's only a matter of time before someone gets it working. That someone may not be nice and let us know about it though. Hopefully I'm wrong, but I'd rather enable KTPI wherever I can at the moment.
As for why would AMD mislead? They may not be, they may sincerely believe they are immune, but without an explanation why, you're still blindly trusting their judgement and this wouldn't be the first time engineers missed a hole in their own product.
Keep crying. I'm sure businesses will start taking risks that could cost them billions if you whine loud enough.
Businesses depend to some extent on the goodwill of their customers.
And not only do they frequently make the wrong decision in handling product flaws, they stubbornly refuse to learn that the coverup usually has a worse outcome than the crime.
Pain is merely failure leaving the body
Yes, we agree that opinions vary. Where we don't seem to come to an understanding... That of the human condition it took 2 decades for this flaw, that the designers, according to you, were supposed to have seen through their infallible eye.
I'm way more upset about the Intel ME. That is a far greater and easily exploited vulnerability. Fixing this is just putting lipstick on a pig
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Of course that's jumping from the 'e' line to the 'normal' desktop line. The closest match would now be i9-7940X or i9-7920X, 12 to 14 cores.
XML is like violence. If it doesn't solve the problem, use more.