OpenBSD Journal

Matthew Dillon on Intel Core Bugs

Contributed by deanna on from the interesting dept.

Buried deep in a pile of slashdot comments, Matthew Dillon of DragonFly gives a detailed assessment of the Intel Core bugs. While a lot of news sites and bloggers were quick to dismiss the issue as inflated, Dillon's comments provide a much closer look at the actual issues.

"So, in summary, AE3 scares the hell out of me, and for the others AE5, AE8, AE21, and AE30 look serious."

His comments are actually so detailed that it's impractical to reproduce them here. The ones he mentions specifically:

AE3 - POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.

AE5 - Memory aliasing with inconsistent dirty and Access bits may cause a processor deadlock. This means a PTE with 'D'irty set but with 'A'ccess not set. FreeBSD and DragonFly always set the A bit when setting the D bit and will not be effected but I don't know about other OSs. This is a very serious bug though.

AE8 - FXSAVE after FNINIT without an intervening FP instruction may save uninitialized values for FDP and FDS. This isn't an issue unless the data being written represents a security leak of some sort, such as a portion of the state of another program's FP unit. This could be a security issue with regards to one program snooping another program's cryptography. Statistical snooping possible through this sort of mechanic has been shown to be effective in recent years.

AE21 - The execution disable bit is shared between cores. I'm not sure what this means but Intel seems to think that it compromises an anti-hacker feature. Sounds pretty serious.

AE30 - Global pages in the DTLB may not be flushed by RSM instructions before restoring the architectural state from SMRAM. This is catastrophic for any software that uses global pages in SMM mode. It means that no software can use global pages in SMM mode. Operating systems usually do not have any control over what is run in SMM mode so this is a BIOS issue for the most part.

(Comments are closed)


  1. By Anonymous Coward (cnst) on

    thanks, Deanna, nice catch!

  2. By Anonymous Coward () on

    AE3: "unpredictable behavior" is just marketing speak meaning that it doesn't perform exactly to spec. It doesn't mean "flip the processor into supervisor mode" or "turn paging off". Here it is likely something more like you can take a single-step exception immediately after doing a POPF instruction instead of after the following instruction. There are likely other factors that have to coincide for this to be the case.

    AE5: "may cause" implies that there are other factors involved (i.e. simply having the dirty bit set but not the accessed bit set won't cause the problem).

    AE21: to me, this means that clearing the EFER.NXE bit on one core will clear it for the other core (in a dual-core chip, of course). Of course, setting it on one would then set it on the other as well.

    1. By Jimbo () on

      quoting an OSNews user:

      "Some inaccuracies..
      By Brendan (2.03) on 2007-06-30 13:42:35 EST
      Hi,

      AE3 - POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.

      This was deleted from the errata in September 2006. I've no idea why (it's rare for this to happen, and I can only assume it was wrong to begin with, and possibly reworded and shifted to a new errata item when more accurate information became available).

      AE5 - Memory aliasing with inconsistent dirty and Access bits may cause a processor deadlock. This means a PTE with 'D'irty set but with 'A'ccess not set. FreeBSD and DragonFly always set the A bit when setting the D bit and will not be effected but I don't know about other OSs. This is a very serious bug though.

      Intel manuals have been warning against inconsistant A and D flags for ages. It's not a serious bug, it's just a reminder for people that didn't read the programming manual properly.

      AE8 - FXSAVE after FNINIT without an intervening FP instruction may save uninitialized values for FDP and FDS. This isn't an issue unless the data being written represents a security leak of some sort, such as a portion of the state of another program's FP unit. This could be a security issue with regards to one program snooping another program's cryptography. Statistical snooping possible through this sort of mechanic has been shown to be effective in recent years.

      This is BS. If the OS initialises the FPU state in any way that could be considered secure when a process is started, then information can't leak from one process to another (with or without this bug) as the new process would load it's own full state when FXLOAD is used during (or after) the task switch.

      AE21 - The execution disable bit is shared between cores. I'm not sure what this means but Intel seems to think that it compromises an anti-hacker feature. Sounds pretty serious.

      This is another "non-event". An OS either supports execution disable and enables it for all cores, or doesn't support execution disable and doesn't enable it for all cores. User-level code can't control this flag. Virtual machine monitors (e.g. VMX) virtualize the flag.

      AE30 - Global pages in the DTLB may not be flushed by RSM instructions before restoring the architectural state from SMRAM. This is catastrophic for any software that uses global pages in SMM mode. It means that no software can use global pages in SMM mode. Operating systems usually do not have any control over what is run in SMM mode so this is a BIOS issue for the most part.

      This bug only effects BIOS/SMM code. Global pages are used by OSs to reduce TLB flushes when switching between virtual address spaces, but BIOS/SMM code has no reason to switch between virtual address spaces (and no reason to use global pages).

      So in summary, everything that Matthew Dillon thinks might look serious isn't worth yawning at....


      Cheers,

      Brendan"

      http://osnews.com/permalink.php?news_id=18178&comment_id=252013

      1. By Lars Hansson () lars@unet.net.ph on

        > quoting an OSNews user:
        >
        > "Some inaccuracies..

        And we should believe this "Brendan" guy because...?

  3. By Curt Micol () asenchi@asenchi.com on

    I am very glad he went through these. We need more people standing up for open source and not writing off Theo as a retard, which seems to be the way most people handle his comments.

    Thank you Matt, and thank you Theo & devs for standing up for all of open source and fighting ridiculous bugs and companies.

    1. By Anonymous Coward () on

      > I am very glad he went through these. We need more people standing up for open source and not writing off Theo as a retard, which seems to be the way most people handle his comments.

      I love this precise mails *thumbsup* there should be more of them so no one is going to call Theo "irantwithstyle" de Raadt a retard again.

  4. By Anonymous Coward () on

    Interesting and scary stuff.

    Always more to learn, find, research, or whatever. Now looking at if there are any serious OSS CPU/motherboard diagnostic programs? Sure, one might be able to write some tests, but sure would be nice if CPU manufactures gave out their programs for this. I guess OpenBSD has spoiled me into wanting it all, for free.

    Don't want anymore foof bugs or haunted computers.

  5. By Anonymous Coward () on

    Hmm...looks like the VIA C7 just got another reason to be considered. Of course an Intel Core 2 Duo will outrun it, clock for clock. But then, if you're doing crypto and want to do so on a budget, VIA's crypto engine is said by Theo, et. al. to be the fastest they've ever worked with.

    Reasons to use a VIA C7:

    1.) Good (not great, but good) general all-around performance. At 2GHz, it actually makes a fine desktop box CPU.

    2.) *Astonishing* crypto performance. If you're building a VPN gateway, the C7 kicks butt. After reading the OpenBSD team's testimonial about the C3, I made an IPSec gateway out of a C7, and yes, it does rock. Totally blows away anything from Intel and AMD.

    3.) Very low power usage. When the chip's running *at full tilt*, it uses 20W. That's less than even the Pentium M.

    4.) The ability to run the thing fanless. Granted that the 2GHz version needs a fan, but the 1GHz version--and all of the Eden lines--do not. That's a good thing, especially for a firewall and/or VPN gateway.

    5.) Reasonable cost. A motherboard/CPU combination for 1.5GHz can be had for about $230 as of today, 1 July 2007. The 2GHz version isn't much more.

    6.) As with the AMD CPU's, I've not heard that the C7 is susceptible to these problems that plague the Core 2 Duo.

    1. By RC () on

      > Hmm...looks like the VIA C7 just got another reason to be considered.

      I'd go for AMD, not VIA.

      > Reasons to use a VIA C7:
      >
      > 1.) Good (not great, but good) general all-around performance.

      What you call "good" "performance" I call horrible performance.


      > 2.) *Astonishing* crypto performance. If you're building a VPN gateway, the C7 kicks butt.

      I'd just throw a $100 crypto card in a non-VIA system myself...

      > 3.) Very low power usage. When the chip's running *at full tilt*, it uses 20W. That's less than even the Pentium M.

      No it isn't. It's only less power if you compare it with processors that can run circles around it. There are many processors that can easily outperform it using less power.

      If you want a comparison to VIA's CPUs, try benchmarking an AMD Geode NX 1500@6W.

      > 5.) Reasonable cost. A motherboard/CPU combination for 1.5GHz can be had for about $230 as of today, 1 July 2007. The 2GHz version isn't much more.

      That's not cheap at all.

      Geode CPU + motherboard can be found for under $150.

      Socket 754 mobo + 25W 2GHz Turion CPU goes for under $200.

      Hell, a 20W 1GHz Sempron CPU + Socket A mobo can be found for $60.

      I really don't understand the commercials for VIA CPUs around here. I've owned a couple, and I couldn't stand them for long. Got a 1GHz setting around here for months now... replaced it with an even lower power Intel CPU almost immediately after buying it.

      1. By Anonymous Coward () on

        AMD's errata is 4x as long as Intel's. Doesn't seem like a very bug-free way to go.

        1. By Anonymous Coward () on

          > AMD's errata is 4x as long as Intel's. Doesn't seem like a very bug-free way to go.

          It's not so much the length of the errata, as what is contained within it.

      2. By Anonymous Coward () on

        > > Hmm...looks like the VIA C7 just got another reason to be considered.
        >
        > I'd go for AMD, not VIA.

        I've certainly got nothing against AMD CPU's; I have several.

        >
        > > Reasons to use a VIA C7:
        > >
        > > 1.) Good (not great, but good) general all-around performance.
        >
        > What you call "good" "performance" I call horrible performance.
        >

        I have to disagree here. I've found the performance of mine quite acceptable; the C7 fixed a lot of the (non-crypto) performance issues that the C3 had.

        >
        > > 2.) *Astonishing* crypto performance. If you're building a VPN gateway, the C7 kicks butt.
        >
        > I'd just throw a $100 crypto card in a non-VIA system myself...
        >

        Could you point us in the direction of a good one for that price that works w/ OpenBSD and doesn't suck up a ton of power? I would certainly be interested. A friend of mine wants a VPN gateway, and I was going to use a VIA-based solution.

        > > 3.) Very low power usage. When the chip's running *at full tilt*, it uses 20W. That's less than even the Pentium M.
        >
        > No it isn't. It's only less power if you compare it with processors that can run circles around it. There are many processors that can easily outperform it using less power.
        >

        One of those is the PowerPC 750GX (G3) CPU, one of my favorites. Unfortunately, they're getting harder to come by for desktop CPU's without spending a fortune; x86 economies of scale come into play here.

        > If you want a comparison to VIA's CPUs, try benchmarking an AMD Geode NX 1500@6W.

        I've not yet played around with the Geodes. I'll take a look.

        >
        > > 5.) Reasonable cost. A motherboard/CPU combination for 1.5GHz can be had for about $230 as of today, 1 July 2007. The 2GHz version isn't much more.
        >
        > That's not cheap at all.
        >
        > Geode CPU + motherboard can be found for under $150.
        >
        > Socket 754 mobo + 25W 2GHz Turion CPU goes for under $200.
        >
        > Hell, a 20W 1GHz Sempron CPU + Socket A mobo can be found for $60.

        To get the crypto support, we'd need to add $100, per the above. Also, we'd need to ensure that the system as a whole is just as low-power, since the chipset and the crypto card also eat juice. Hmm...that's actually worth looking into.

        1. By Anonymous Coward () on

          > > > 2.) *Astonishing* crypto performance. If you're building a VPN gateway, the C7 kicks butt.
          > >
          > > I'd just throw a $100 crypto card in a non-VIA system myself...
          > >
          >
          > Could you point us in the direction of a good one for that price that works w/ OpenBSD and doesn't suck up a ton of power? I would certainly be interested. A friend of mine wants a VPN gateway, and I was going to use a VIA-based solution.

          $68 - $76 (miniPCI vs PCI) http://www.soekris.com/vpn1401.htm

          I like my C7 though. I think it is going to make for a great OpenBSD secured WAP.

          1. By Anonymous Coward () on

            > > > > 2.) *Astonishing* crypto performance. If you're building a VPN gateway, the C7 kicks butt.
            > > >
            > > > I'd just throw a $100 crypto card in a non-VIA system myself...
            > > >
            > >
            > > Could you point us in the direction of a good one for that price that works w/ OpenBSD and doesn't suck up a ton of power? I would certainly be interested. A friend of mine wants a VPN gateway, and I was going to use a VIA-based solution.
            >
            > $68 - $76 (miniPCI vs PCI) http://www.soekris.com/vpn1401.htm
            >
            > I like my C7 though. I think it is going to make for a great OpenBSD secured WAP.
            >


            Hey, that does look pretty good. Hmm...that means I'm not limited to x86, either. This could be interesting, indeed. Thanks!

  6. By Anonymous Coward () on

    Does those bugs appears to Core Duo and Core 2 Duo? Or only to Core 2 Duo?

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