OpenBSD Journal

Intel Core 2 considered evil

Contributed by deanna on from the f00f-with-a-vengeance dept.

toxa points us to Theo's recent post on misc@:
Various developers are busy implementing workarounds for serious bugs in Intel's Core 2 cpu.

These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code.

As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors' bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold.

Full (current) errata from Intel:

http://download.intel.com/design/processor/specupdt/31327914.pdf

  • We bet there are many more errata not yet announced -- every month this file gets larger.
  • Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs.
  • Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).
  • Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences.
  • All of this is just unbelievable to many of us.
An easier summary document for some people to read:

http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif

Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.

As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries).

At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent.

(While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too).

For more, read the entire thread.

(Comments are closed)


Comments
  1. By Noryungi (Noryungi) noryungi@yahoo.com on

    Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored.

    Ouch! What's the point of having non-exec bits if they are not respected by the CPU? This is very serious, indeed.

    Hopefully, OpenBSD developpers and users will raise enough problems that Intel will fix these. But I am not very hopeful, as Intel has proved very uncooperative in the past.

    In the meantime, I am looking at my old Sun workstation in a different light...

    Comments
    1. By Cabal (Cabal) on http://www.enginuity.org/

      Isn't this why the CPUs are microcode-reflashable? Intel provides updated microcode, which motherboard manufacturers flash during POST, or failing that, people can do it themselves (example on Linux). Is the issue that Intel isn't fixing problems at all or that we don't like volatile reflashes?

    2. By Anonymous Coward (71.232.225.252) on

      > Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. > Ouch! What's the point of having non-exec bits if they are not respected by the CPU? This is very serious, indeed. > Hopefully, OpenBSD developpers and users will raise enough problems that Intel will fix these. But I am not very hopeful, as Intel has proved very uncooperative in the past. > In the meantime, I am looking at my old Sun workstation in a different light...

      Already fixed.

      http://blog.springdaemons.com/articles/2007/05/03/intel-critical-microcode-update

      Comments
      1. By henning (213.39.215.230) on

        > Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored.
        > Ouch! What's the point of having non-exec bits if they are not respected by the CPU? This is very serious, indeed.
        > Hopefully, OpenBSD developpers and users will raise enough problems that Intel will fix these. But I am not very hopeful, as Intel has proved very uncooperative in the past.
        > In the meantime, I am looking at my old Sun workstation in a different light...
        >
        > Already fixed.
        >
        >http://blog.springdaemons.com/articles/2007/05/03/intel-critical-microcode-update

        people just don't get it.

        first, intel provides the microcode updates only to MS and hardware vendors. if you don't run windows and your hardware vendor does not supply a bios upgrade, you're doomed. And we all know how good hardware vendors are at suplying updated bioses...

        second and more importantly, there updates by intel only fix a FEW of these problems, a LOT are left. there's some indicators that some of these issues are not microcode fixable. and intel clearly stated that they will not fix some others.

        Comments
        1. By Anonymous Coward (85.178.73.96) on

          > > Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored.
          > > Ouch! What's the point of having non-exec bits if they are not respected by the CPU? This is very serious, indeed.
          > > Hopefully, OpenBSD developpers and users will raise enough problems that Intel will fix these. But I am not very hopeful, as Intel has proved very uncooperative in the past.
          > > In the meantime, I am looking at my old Sun workstation in a different light...
          > >
          > > Already fixed.
          > >
          > >http://blog.springdaemons.com/articles/2007/05/03/intel-critical-microcode-update
          >
          > people just don't get it.
          >
          > first, intel provides the microcode updates only to MS and hardware vendors. if you don't run windows and your hardware vendor does not supply a bios upgrade, you're doomed. And we all know how good hardware vendors are at suplying updated bioses...
          >
          > second and more importantly, there updates by intel only fix a FEW of these problems, a LOT are left. there's some indicators that some of these issues are not microcode fixable. and intel clearly stated that they will not fix some others.

          That`s absolutly true henning.
          Well but aside this on Linux you could at least "Flash" the Microcode and fix at least these "few" things.

          On OpenBSD I wouldn't know a method to do this (I don't wanna blame OpenBSD I just never searched for such a possibility).
          Propably such a tool is worth the effort of coding it.

          Well but AMD isn't "that better" I guess.
          Every CPU has issues and that's why most Vendors do suck....
          Seams nobody is able to produce anything correctly anymore.
          Sure... Bugs do happen but guys: Such serious Bugs? :-)

          Comments
          1. By sthen (85.158.44.149) on

            > Well but aside this on Linux you could at least "Flash" the Microcode and fix at least these "few" things.

            it's no flash, it's a runtime patch. and one part of the problem is that this patch is not allowed to be distributed as part of the OS.

            > Well but AMD isn't "that better" I guess.

            well, some motherboard manufacturers still drag their heels over updating BIOS to fix errata where AMD published fixes long ago. I think we can safely assume that some boards will never see the already-released microcode incorporated in BIOS. *especially* seeing as Windows loads it already.

            > Every CPU has issues and that's why most Vendors do suck....
            > Seams nobody is able to produce anything correctly anymore.
            > Sure... Bugs do happen but guys: Such serious Bugs? :-)

            ...this is the *published* stuff. Some of those graphic cards and various other devices (aac and others) must suck *really* badly.

            Comments
            1. By Anonymous Coward (132.198.23.146) on

              > > Well but aside this on Linux you could at least "Flash" the Microcode and fix at least these "few" things.
              >
              > it's no flash, it's a runtime patch. and one part of the problem is that this patch is not allowed to be distributed as part of the OS.


              Lenovo, for example, has provided BIOS updates as bootable iso-images. I recently applied the update to my Lenovo ThinkPad that only runs OpenBSD.

              So, you don't have to be running a Microsoft operating system to apply the BIOS patch!

              See

              http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-67648

              Comments
              1. By Igor Sobrado (sobrado) on

                > > it's no flash, it's a runtime patch. and one part of the problem is that this patch is not allowed to be distributed as part of the OS.
                >
                >
                > Lenovo, for example, has provided BIOS updates as bootable iso-images. I recently applied the update to my Lenovo ThinkPad that only runs OpenBSD.
                >
                > So, you don't have to be running a Microsoft operating system to apply the BIOS patch!

                A firmware upgrade and a runtime patch to the microcode are not the same. Think on the latter as the firmware upload process in some wireless network devices (e.g., iwi(4)). You need to upload the firmware each time you want to use the network adapter; same about patching the processor. A user is doomed if the microcode cannot be freely distributed with the operating system. A firmware upgrade is a one-time upgrade. Once upgraded, the new firmware remains on the device forever; a runtime patch needs to be applied each time the device is used.

                I am glad you ask about IBM/Lenovo ThinkPads. I am very disappointed with Lenovo technical support staff. They are not serious about firmware bugs fixing on the ThinkPad T43 (most of these bugs are widely known):

                Bug #1: fan control loop status is not initialized

                Description: the Embedded Controller does not correctly initializes the fan control register (0x2f), some ACPI implementations cannot determine the correct status of the fan control until something writes to the fan control register for the first time.

                Consequences: there are reports of wrong readings of 0x07. However, 0x07 might be a correct value if the system is in emergency fan mode (i.e., at level 7).

                Workaround: as outlined in this report, writing to the fan control register in their ACPI DSDT methods provides a workaround, but the problem must be fixed in firmware.

                Bug #2: fan control loop pulses the fan in an annoying pattern

                Description: the fan control loop will vary the fan speed quite a lot, in a very annoying pattern. A fix has been released for ThinkPads TP-1R (T40, T40p, T41, T41p, T42, T42p) and TP-1Y (T43, T43p) but the fix provided for models TP-1Y is broken.

                Consequences: The broken fix on the T43 firmware causes very loud and annoying pulses every thirty seconds.

                Workaround: unknown. (some ACPI implementations could take control over the fan loop, but the problem is in the firmware and we should not rely on third parties to fix it).

                Bug #3: tachometer registers not updated when entering or exiting disengaged mode

                Description: when the fan control loop is placed in disengaged mode (bit 6 of Embedded Controller register 0x2f transitions to set), the ThinkPad models TP-1Y (T43, T43p) and TP-79 (T60, T60p) will not read the tachometer while the fan is speeding up. It takes quite a while for the fan to speed up, so the tachometer can be stale for a long time, close to a full minute. The same also happens when exiting disengaged mode (i.e., bit 6 of the Embedded Controller register 0x2f transitions to clear).

                Consequences: during this time window, fan monitoring report incorrect speeds.

                Workaround: unknown.

                Bug #4: tachometer registers not invalidated in disengaged mode

                Description: when the fan control loop is entering or leaving disengaged mode (i.e., bit 6 of the Embedded Controller register 0x2f changes state), ThinkPads TP-1Y (T43, T43p) and TP-79 (T60, T60p) at least will not update the tachometer for quite a while. On those ThinkPads, and perhaps others supporting disengaged mode, the Embedded Controller does not set the tachometer registers (0x84 and 0x85) to 0xff to signal an invalid reading. Instead, the registers are simply not updated and retain the last valid tachometer reading.

                Consequences: invalid tachometer readings, but is it a bug or a feature?

                Workaround: unknown.

                Bug #5: Adaptec 2940x PCI SCSI interfaces cannot be attached to the Dock II

                Description: the Adaptec 2940x PCI SCSI interfaces cannot be attached to the IBM Dock II (and probably other IBM docking units) because the T43 firmware is unable to load the 2940x ROM extensions.

                Consequences: when an Adaptec 2940x PCI SCSI interface is added to the docking unit, the ThinkPad T43 attached to it (and probably other ThinkPad models too) cannot boot.

                Workaround: unknown.

                (some fixes for the first four bugs have been proposed in public forums recently. OpenBSD is doing a great job fixing bugs too, at least the annoying fan pulse-noise is difficult to see when running this operating system.)

                The answer from the technical support team is really annoying: "Your system indicates it is beyond its Software warranty period of 30 days. To obtain software support which will be billable or to obtain free hardware Support, please phone the Technical HelpCentre of your country."

                If we see a computer architecture as a series of abstraction layers, firmware will be the second one, just over the hardware abstraction layer and below what we usually call software (kernel and userland).

                So, I will not trust on Lenovo (or other manufacturer) firmware updates. They are here for business, not to develop quality products. Period. That is the reason I really like operating systems like OpenBSD: developers like what they are doing and will work very hard to fix each bug and provide the best quality products. That is the reason I strongly suggest supporting these development teams.

                It would be nice if someone with a good knowledge on H8/300 assembler releases an unofficial Embedded Controller firmware for these systems addressing these bugs.

                In short, bootable firmware upgrade CD-ROMs are great but firmware upgrades not address all bugs. Sometimes, these upgrades must be applied as runtime patches that have strong restrictions to their distribution.

            2. By Amir S Mesry (70.43.112.117) starkiller@web-illusions.net on

              > > Well but aside this on Linux you could at least "Flash" the Microcode and fix at least these "few" things.
              >
              > it's no flash, it's a runtime patch. and one part of the problem is that this patch is not allowed to be distributed as part of the OS.
              >
              > > Well but AMD isn't "that better" I guess.
              >
              > well, some motherboard manufacturers still drag their heels over updating BIOS to fix errata where AMD published fixes long ago. I think we can safely assume that some boards will never see the already-released microcode incorporated in BIOS. *especially* seeing as Windows loads it already.
              >
              > > Every CPU has issues and that's why most Vendors do suck....
              > > Seams nobody is able to produce anything correctly anymore.
              > > Sure... Bugs do happen but guys: Such serious Bugs? :-)
              >
              > ...this is the *published* stuff. Some of those graphic cards and various other devices (aac and others) must suck *really* badly.

              You have no idea.
              I worked with Intel on one of the EOLed PAE systems. It was a nightmare.
              CPU Issues, being backplane CPU, SafTE CPU, PCI Bus Signal issues.

              Not to mention they had a Chipset Issue a few years back that was fixed, but they didn't release the fix.

              Intel is Horrific. They just get lucky sometimes in that it's patchable.

          2. By Anonymous Coward (128.171.90.200) on

            > Well but aside this on Linux you could at least "Flash" the Microcode and fix at least these "few" things.

            AI79, may be fixed in a future stepping of the product
            AI43, may be fixed in a future stepping of the product
            AI39, may be fixed in a future stepping of the product

            AI65, There are no plans to fix this
            AI90, There are no plans to fix this
            AI99, There are no plans to fix this

  2. By Anonymous Coward (81.97.30.120) on

    What about Core duo processors Does this include them aswell?

    Comments
    1. By Anonymous Coward (217.11.231.73) on

      > What about Core duo processors Does this include them aswell?

      Probably not, as Intel Core is part of the Pentium-M line.
      Its name is only a marketing trick.

  3. By Anonymous Coward (212.112.241.44) on

    There should be a warning at install time that it's impossible to secure this OS.

    Comments
    1. By ciphernaut (61.9.221.177) on

      > There should be a warning at install time that it's impossible to secure this OS.

      Warning! You are part of this universe. You cannot be isolated from all of the effects contained therein.

  4. By Anonymous Coward (216.68.198.57) on

    I never trusted the Core 2 from the start. Got a Lenovo T43 for a customer, instead of Core 2. Would like to use AMD, but no protection on microcode updates, and hacker code out there a while ago = stick with Intel P3,4,M. Arguable. yes, but most laptop users don't use make.

    OpenBSD, Single CPU, and low overhead programs, mutt, rather than thunderbird, more business grade, although users will complain.
    < Redacted statement about Intel and business >
    < Redacted statement about Intel and why business users would trust ...>
    Business is war. Cyberwar is getting mainstream.

    Any comments on VIA C7 types and OpenBSD? Haven't looked at. Perhaps OpenBSD can get more friendly with another CPU maker?

    Peace all, and thank you for pursuing these security issues, that most want to sweep under the rug.

    Comments
    1. By Anonymous Coward (216.68.198.57) on

      It depends upon what you expect from these processors. Security is not an issue with mainstream world, period.

      Crypto processors, such as IBM hardened and others implement a lot of security, sort of, but none still are perfect, that what civilians get stuck with.

      AMD might be great with documentation, but its got serious issues as well.

      And mod ratings sure don't count for good advise either, thats deceptive, although not evil.

      Peace all.
      ...

  5. By Anonymous Coward (151.38.126.254) on

    You might find some interesting things about cpu bugs in this 4 months old interview by the usual suspect.

  6. By Anonymous Coward (87.15.209.236) on

    you guys rocks!! bring it on the show!! ive never buy an intel core duo... im a lucky one!! wow

  7. By Chas (147.154.235.53) on

    I heard somewhere that certain Core 2 Duo high-performance functions were disabled for 64-bit code.

    Given that Vista will be the last 32-bit Microsoft OS, is AMD a better choice, also given the Intel errata?

    Openbsd's 32-bit support will probably continue for a long, long while, but it's good to move with the times.

    Comments
    1. By Anonymous Coward (155.212.206.114) on

      > I heard somewhere that certain Core 2 Duo high-performance functions were disabled for 64-bit code.
      >
      > Given that Vista will be the last 32-bit Microsoft OS, is AMD a better choice, also given the Intel errata?
      >
      > Openbsd's 32-bit support will probably continue for a long, long while, but it's good to move with the times.

      AMD's errata is 4x as long as Intel's.

      Comments
      1. By henning (80.171.66.23) on

        > AMD's errata is 4x as long as Intel's.

        it should be totally obvious that the sheer length of the errata list doesn't tell much...

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]