According to these reports from the OpenBSD-misc mailing list, Intel’s Core Duo is buggy, and upcoming features on Intel motherboards create a second running environment accessible even when your computer is off, both of which create security risks. (Thanks, Hasso Tepper)
Before anyone starts to hyperventilate, keep in mind: 1: this is a warning of potential problems, not an assessment of existing problems. 2: It’s an OpenBSD mailing list, which can be described as ‘adversarial’.
I wouldn’t call it adversarial there, just demanding, they demand people read the mailing list archives, google and read the faq before making comments, that’s all. They’re not your enemy unless you’ve skipped those three and gone straight to commenting.
Scary errata, per Theo:
AI65: Thermal monitoring broken, don’t expect a warning before CPU halts or melts.
AI79: DoS possible by ugly on-chip race, patchable.
AI43: Hyperthreading considered dangerous off-the-shelf, patchable.
AI39: Sharing L2 is complicated, coherency is broken off-the-shelf, patch available.
AI90: “Page Access Bit May be Set Prior to Signaling a Code Segment Limit Fault”
— No fix, use guard pages.
AI99: “Updating Code Page Directory Attributes without TLB Invalidation May Result in
Improper Handling of Code #PF”
— No fix, when bumping up against the TLB bug(?), page faults take precedence
over general protection faults and may mask debug exceptions.
The GIF does a better job than I do, though that’s for the original Core Duo. (Intel code AE vs. AI, probably some duplication.)
It’s going to be annoying to discover hardware that prevents AMT from being disabled (how many of you are sure of your Wake-on-LAN settings?). Otherwise it’s a cute trick with all the benefit and risk of TCP/IP’s routability.
Yeah, there are a lot of “show stopper” bugs, and even a few “potential catastrophic” bugs. Of course, it’s a complex design, but I have the feeling they were rushing.
But bugs in processors are nothing new; only that there are so many of them in a single one is shocking.
I’d love to say there’s an interesting discussion on slashdot
http://hardware.slashdot.org/hardware/07/06/28/1124256.shtml
But there isn’t ;).
(Can’t edit comments, right?)
It’s strange that Linus doesn’t really think it’s a problem:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=80552&threadid=80534&roomid=2
Instead, he think it’s more a documentation issue.
“Instead, he think it’s more a documentation issue.”
And yet man 9 foo on Linux does nothing ;^)
Saying they are adversarial is a bit disrespectful. I am an avid OpenBSD user (along with DragonFlyBSD) and they are ones to stand up for their principles. They work very hard for the open source community, I’ve never understood why people trash them.
Stand up for what you believe, fight for what you believe, don’t trash others who do these things. They’ve fought long and hard to keep things open, yet no one else seems to stand with them when it counts. Instead people call them “adversarial”. Sorry if I am coming off harsh, but I was shocked to see this statement made. It was a bit disconcerting…
Curt, I think you are misunderstanding my use of the word ‘adversarial’. What do you think “fight for what you believe” means?
Besides, I doubt any OpenBSD developers are shocked, SHOCKED! about a blog entry somewhere that describes them as aggressively opinionated.
The OpenBSD people use a much more explicit language when it comes to other OSes. For instance, they called NetBSD a broken OS just because they could not maintain binary compatibility with it. Or look at this blog’s double pf speed entry — they are very proud of that PF speedup and did not give credits to Jörg Sonnenberger.
And every piece of hardware that they do not support is ‘crap’, ‘broken’ etc. But respect for their drivers and Open* programs (SSH, BGPD etc.)