Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Intel Businesses Security Hardware

When F00F Bug Hit 20 Years Ago, Intel Reacted the Same Way (itwire.com) 141

Posted by msmash from the blast-from-the-past dept.
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'."
This discussion has been archived. No new comments can be posted.

When F00F Bug Hit 20 Years Ago, Intel Reacted the Same Way More

When F00F Bug Hit 20 Years Ago, Intel Reacted the Same Way

Comments Filter:

  • So you're saying (Score:5, Funny)

    by Anonymous Coward on Friday January 05, 2018 @09:08AM (#55868337)

    This isn't the 0.9998356st time they've done this?

    • Grats on 0.9998356st post

    • Re:So you're saying (Score:5, Insightful)

      by 4im ( 181450 ) on Friday January 05, 2018 @10:12AM (#55868759)

      Exactly... I still own a Pentium 90 with FDIV bug, couldn't manage to get it replaced. As I recall, it took Intel quite a while to acknowledge the seriousness of the FDIV issue, before they caved and opened a rather complicated exchange program. A pre-condition was to give them your credit card number... which, as a youth, I didn't have then. Also, I couldn't exactly wait out a weeks-long procedure (sending back the CPU and getting a fixed version back) without a working PC. When I first went to the shop where I bought that computer, they didn't have an exchange program yet, the next time it supposedly was already past... all BS.

      Afterwards, I've been a long-time AMD customer (K6-2 350, Athlon 800, Athlon64 X2), going back to Intel for my more recent acquisitions (laptops, netbook, more recently a low-power server). I guess my next box will be a Ryzen...

      • It should be noted that while AMD is safe from Meltdown, they're still vulnerable to Spectre.

        • Re: So you're saying (Score:1)

          by Anonymous Coward

          Those two are not even remotely equal though. Meltdown is serious and will demand shenanigans in code to mitigate for anlong time to come: A Ryzen or Epyc purchase lets you skip that.

  • 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 art

    • 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 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?

      • Re: (Score:2, Troll)

        by Khyber ( 864651 )

        "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!

        • 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

          • 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 would like to issue you two challenges.
            1) design a CPU from scratch that is even 1/100th as powerful as a current gen CPU.
            2) Starting with x86 PIII (where this issue first existed IIRC) design a multicore part even half as good as a modern CPU.

            • Re: (Score:1)

              by Anonymous Coward

              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.

          • Re: "Why Intel gave it the mind-numbingly boring n (Score:5, Informative)

            by El Cubano ( 631386 ) on Friday January 05, 2018 @11:56AM (#55869513)

            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.

            • 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

      • Costs (Score:3)

        by sjbe ( 173966 )

        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 t

      • Re: (Score:2)

        by brunes69 ( 86786 )

        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.

        • It looks like we are even at this point :)

        • 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.

    • Re:"Why Intel gave it the mind-numbingly boring na (Score:5, Informative)

      by El Cubano ( 631386 ) on Friday January 05, 2018 @09:20AM (#55868407)

      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.

      • 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 force

      • Re: (Score:1)

        by Anonymous Coward

                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.

    • Re: (Score:2)

      by rickmoen ( 1322 )

      I'm not sure I understand the point of this article.

      Condolences. But if you ponder long and hard, you might spot the pattern [tomshardware.com]

      Rick Moen
      rick@linuxmafia.com

  • ...to the 0xDEADBEEF bug?

  • Random guy on internet angry at Intel (Score:1)

    by Anonymous Coward

    I'm pissed at them too - where is my slashdot article?

  • Execute, not send (Score:5, Insightful)

    by tjansen ( 2845 ) on Friday January 05, 2018 @09:23AM (#55868441) Homepage
    '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.
    • Indeed. If you are allowing remote attackers to send instruction sequences that your CPU will execute directly, then you have far bigger problems than the f00f bug. Simply causing your computer to crash is probably the least malicious thing that they can do.

    • not a huge deal 20 years ago, when computers with Intel CPUs were almost always single-user machines

      20 years ago we'd had Windows 95 OSR 2 and Windows 98 was close to shipping. People were already hooked up to the Internet and all that shoddy code with its buffer overflows and use-after-free bugs was pristine and untroubled by fuzzers and static analysis. It wasn't a huge deal because writing remote exploits hadn't yet become popular, not because such exploits were impossible. And, of course, there was a hacky sort of OS mitigation.

    • Re: (Score:2)

      by haruchai ( 17472 )

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

      There were many ways to remotely kill or compromise machines back then. A friend who worked tech support would get pesky customers off the phone by WinNuke'ing them

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

  • I noticed yesterday that their "facts" article [intel.com] they're already claiming their processors have no bug and are working as intended:

    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.

    • They are correct: their processors are working as intended. The problem is that their intent did not take this scenario into consideration. Whether you call that a "bug" or not is debatable, but you don't really expect their PR department to call it that, do you?

  • This bug is much worse (Score:5, Interesting)

    by 110010001000 ( 697113 ) on Friday January 05, 2018 @09:36AM (#55868521) Homepage Journal
    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.
  • I love how everyone seems to be vilifying Intel when AMD and ARM have the same issues.

    • Re:What about the rest of them? (Score:4, Informative)

      by thegreatbob ( 693104 ) on Friday January 05, 2018 @09:50AM (#55868611) Journal
      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: (Score:2)

      by XanC ( 644172 )

      They don't. Spectre is an industry-wide problem. The far more egregious Meltdown seems to be an Intel problem.

    • Actually, reading back through, apparently some very specific ARM stuff is Meltdown-compliant too. So AMD is the only one in the clear for now.

  • Differences of Intel's most famous 3 problems (Score:5, Informative)

    by Junta ( 36770 ) on Friday January 05, 2018 @09:40AM (#55868545)

    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.

    • 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.

      If a recall were to happen, I would imagine it would only apply to chips made within the past 5 years. Anything else would be considered EOL and thus not covered by the recall.

      • 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,

        • Re: (Score:2)

          by xlsior ( 524145 )

          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)

          • 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 w

          • Re: (Score:2)

            by Junta ( 36770 )

            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.

      • Re: (Score:2)

        by Zuriel ( 1760072 )
        That's pretty rough, considering the weak performance improvements we've seen out of Intel for most of the last decade. Six to eight year old computers stack up decently well against the very latest machines, and they'd benefit a lot more from an SSD than a new CPU.

    • Re: (Score:2)

      by xlsior ( 524145 )

      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.

      "way more more massive" doesn't even begin to cover it -- it would include almost every single processor they manufactured over the past 20 years. Even if they wanted to, it would take them longer to manufacturer everyone a replacement processor than the remaining economical lifespan of your computer in the first place... CPU manufacturing plants are insanely expensive, and I seriously doubt that intel has enough spare capacity to 'just' redo their entire production run of the past 5 years on top of their n

  • All around the PCI bus

    The monkey chase the intel

    The monkey thought t`was all in fun

    FOOF goes the intel

  • 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.

    • Re: (Score:2)

      by Dwedit ( 232252 )

      I wonder if microcode could be patched to *undo* caching of data which would have triggered a memory permission exception?

  • It is one of the dangers of anthromorphism. We casually say,

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

  • I've tried this exploit code [react-etc.net] 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".

    • I've tried this exploit code [react-etc.net] 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".

      If you've applied the latest patches, then you're already protected. MS released the patch on Wednesday, January 3rd. I see from a quick search that LineageOS is an Android distro. Google announced their patch early this week, though I don't know which Android distros have incorporated it and pushed a new release. Assuming the exploit you linked is legit, you probably want to test it with an unpatched system instead.

    • How do we know that code is a valid exploit test? Why would it not produce '0' as a result?

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

    • Re: (Score:2)

      by rickmoen ( 1322 )

      Sending, really? What, down a modem, via email, on a webpage?

      Reporter Sam Varghese did slightly misstate things in that sentence, but then quoted me a couple of sentences later with the full picture:

      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 processor instruction 'F0 0F C7 C8'?

      You know, reading with context with improve your life. Give it a t

  • 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 an

    • It would be interesting to see larger companies like Apple or HP fab their own CPUs.

      You still don't know about these [wikipedia.org]?

  • Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997

    No. But I remember the one 1996.987390689

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close