Theo de Raadt Details Intel Core 2 Bugs

Eukariote writes "Recently, Intel patched bugs in its Core 2 processors. Details were scarce; soothing words were spoken to the effect that a BIOS update is all that is required. OpenBSD founder Theo de Raadt has now provided more details and analysis on outstanding, fixed, and non-fixable Core 2 bugs. Some choice quotes: 'Some of these bugs... will *ASSUREDLY* be exploitable from userland code... 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.'"

How hard is it to get right?

[Junior J. Junior III]

We're talking about a few hundred million transistors. I imagine that detecting and fixing bugs when there's that many components involved is really, really difficult. Are other comparably complex processors better? How do AMD, VIA, Motorola, IBM, etc. fare?

Summary sucks, someone please provide better one

[Blahbooboo3]

Uh, the slashdot summary is pretty lousy. After RTFA I am still a bit confused, can someone at slashdot please provide an "english" translation of the problems and how dangerous they are to normal users?

Thanks!

Re:Yay AMD

[Idaho]

Except that if you read what Theo has to say, he doesn't have kind words for AMD either.

Wake me up when Theo has kind words to say about basically anything at all, now *that* would be news!

Unfortunately he's likely also right on most accounts though :(

Shock Felt Round the World

[N8F8]

Coming from the government sector, this kind of issue isn't going to be taken lightly. I work at a DoD facility and all our machines were just refreshed with Core 2 Duo machines. It is already almost impossible to get new software approved, if this causes the same paranoia for basic commodity hardware we're really gonna feel some pain.

Re:How hard is it to get right?

[supersnail]

Except it seems that intel have just arbiteraly changed the way MMU instructions work.

Intel seems to regard these as unpublished improvements rather than bugs.

intel issues

[artjunk]

I am exceedingly ignorant in this area, but even I can grasp how dangerous some of these are. And, as a mac user (PowerPC Dual G5 - thankfully), I suspect that this will come as really bad news to mac community as well. It's unbelievable to me that some of the "Show Stopper" issues are not being addressed by intel - especially when news of nation to nation cyber wars/cyber attacks are beginning to pepper the news. The fact that some of these are not resolvable through software patches is VERY worrisome to me! I am very appreciative to those who can fully interpret these flaws chip architecture and bring it out to the public's awareness.

Re:How hard is it to get right?

[Zontar_Thing_From_Ve]

How do AMD, VIA, Motorola, IBM, etc. fare?

AMD64 doesn't like FreeBSD 6.2 at all. We use FreeBSD and Linux in our business. FreeBSD is very important to us. In fact, I would go so far as to say that the senior management here in our IT department borders on being fanboys of FreeBSD. We were running various versions of FreeBSD on our AMD64 servers from 6.1 down to 5.something and we (foolishly in hindsight) decided that we had to upgrade to version 6.2 because it had some bug fixes we thought we needed. Oh they did fix those bugs, but they opened up a huge one that apparently nobody knows what causes it and nobody has any idea how to fix. What happens is that AMD64 systems will panic with some sort of a "sleeping on a non-sleepable lock" panic. Some people think that this is being caused by a large number of writes. Given how our servers work, this is certainly possible for us. The bottom line for us is that FreeBSD on AMD64 is so unstable that we are probably going to have to go to Linux instead for our web servers. Nobody wants to do that, but we simply can't have our webservers going down every day with the same panic and we lose one server a day on average to this problem. We've even had boxes crash within minutes of being brought up with the exact same panic.

Once we move to Linux, I don't think we'll go back to FreeBSD. My best guess is that because the problem has apparently been going on for months with no resolution that we'll start moving servers from FreeBSD to Linux when we can. We don't have this problem under Linux. The fact is that whether we like it or not, more people use Linux and if stuff is seriously broken under Linux, someone will fix it soon enough. With FreeBSD nobody seems to have any idea what to do for this problem and I'm not sure that it will even be fixed this year, let alone soon enough to keep us from moving to Linux.

Re:Summary sucks, someone please provide better on

[vadim_t]

This is going to be a big deal for shared hosting environments for example.

If you can, as a normal user, execute something that lets you get root on the box, and there's nothing the OS can do to prevent it, then it's a seriously nasty situation for quite a few businesses.

I wouldn't be surprised if businesses like that started switching to AMD hardware.

Quantum effects?

[DFDumont]

My favorite errata in the list is AI22, Sequential Code Fetch to Non-canonical Address May have Nondeterministic Results. Basically the chip decides that all of the high oreder bits should be '1', instead of '0' - for no apparent reason as its not consistent.
Did anyone notice these chips are using the 65nm process?
At what point do the shear quantum affects overcome the deterministic EE rules that are used to design the chips? I don't know, but wikipedia defines a nanoparticle as one with at least one dimension less than 100nm. http://en.wikipedia.org/wiki/Nanoparticle [wikipedia.org]
Given that definition every transistor's source, drain and gate are nanoparticles. And we expect them to behave classically why?

Rush to conquer?

[Applekid]

How does this errata compare to previous generations or even AMDs? I wonder if any increase could be from rushing Core 2 to market to kick AMD's flagship CPU off the top of the heap.

Re:How hard is it to get right?

[Zontar_Thing_From_Ve]

what issues are you seeing?

I thought I explained it pretty well. It's a known problem - a "sleeping on a non-sleepable lock" panic. You can do a web search on it and find some discussion about others who have it, but nobody seems sure about what causes it (a lot of writes is the best guess) and nobody knows how to fix it.

Long story short - 32 bit mode won't work for us as we have to move to 64 bits for growth and future scalability. Using 32 bit FreeBSD is not an option for us. We'll just move to 64 bit Linux rather than move backwards to 32 bit FreeBSD. 64 bit OSes work a lot faster for us than 32 bit. Fast response keeps out customers happy.

Another guy asked why we didn't just fall back to version 6.1 of the kernel. We felt that we needed bug fixes that came out in 6.2 and indeed 6.2 did fix those problems, it just opened up something worse with the panics. Going back to 6.1 will once again give us the bugs we wanted fixed. Again, we might as well just go to Linux as it doesn't have the bugs we faced and it doesn't have the panics on 64 bit AMD that FreeBSD 6.2 does.

Re:How hard is it to get right?

[simm1701]

Well people have been saying for years that hardware is getting more and more like software....

Re:Yay AMD

[MoxFulder]

Dam I really think it would be better if we didn't have a "two party system" in the x86 field. A third (or fourth) vendor would be nice. But given the high barrier to entry, its not going to happen anytime soon.

Heck, it doesn't even have to be x86. I don't use anything but open-source software, so I don't really care one bit about the underlying architecture, as long as it performs well. If somebody builds a well-performing, price-competitive mobo/processor combo that I can drop into my current box, and supports USB/SATA/PCI/2D graphics, I'll use it.

ARM, MIPS64, PowerPC, SPARC, whatever works... I imagine there's a large community of open-source users who would similarly jump ship from x86 if there were an alternative that were competitive on price/performance and flexibility.

Re:Time for RISC?

[p3d0]

What makes you think the bugs are in the "x86 layer"?

wrong

[nanosquid]

IA64 was not a RISC version of x86-like chips, it was a completely new architecture coming out of VLIW work at HP. IA64 architectures had failed once before, and it was a stupid idea for Intel to push them so heavily (personally, I think they will never work because they push too much complexity into software). Switching to IA64 meant that many compilers couldn't be made to work at all, and many other compilers would generate inefficient output.

Intel should be developing a conservative RISC processor, an instruction set similar to PPC but a bit more friendly to transitioning from x86. The adaptation of existing compiler back-ends would be fairly simple. Furthermore, the chip should have backwards compatibility, either through JIT-support or through a small (not necessarily hugely efficient) instruction set translator in the chip.

Itanium is a lesson in how not to handle technological transitions. Itanium was picked by geeks who had no idea of what the market wanted or needed, and Intel marketing and management blindly believed what they were hearing from the geeks. (Another company that works like that is Microsoft, which is why they keep churning out such bad software.)

Re:How hard is it to get right?

[TheGratefulNet]

thanks for the heads up.

I have never seen this but WILL be (now) on the lookout for it. it seems you did find a pretty ugly bug in bsd.

I don't run 64bit mode and I also tend use decent disk i/o cards (3ware in raid1 mode), which I'm led to believe is fully production quality.

(I started using linux in 1995 or so and switched over, almost fully, to freebsd around 1999 or so. I've had almost zero problems with bsd on my production boxes, but these are not multiuser systems - they're LAMP servers (well, minus the L) but they aren't hammered on - they get fairly light duty. still, I've had uptimes that approach a year (reset by a need to physically move the server). I don't think I ever got a full year of uptime on linux - but to be fair, I was always updating the kernel and that has the nasty habit of reseting your uptime.

Re:AI65 Thermal Interrupt is not generated...

[Anonymous Coward]

Ask AMD. Back in 2000 or so, they sold Athlons with no temperature protection, and suffered a huge PR problem when some enterprising individual filmed an Athlong bursting into flames after the heatsink was removed from a running machine. I'm waiting for someone to do the same for an Intel Core 2 Duo... imagine the entertainment potential!

The bugs aren't really the scary part,

[yAm]

the AMT (Advanced Management Technology) is the truly frightening bit. Big Brother visits your computer:

A Swedish ASIC designer explains:
http://strombergson.com/kryptoblog/?p=311 [strombergson.com]

(A rough) translation:
http://marc.info/?l=openbsd-misc&m=118302016430106 &w=2 [marc.info]

Re:Yay AMD

[kestasjk]

Wake me up when Theo has kind words to say about basically anything at all, now *that* would be news!

Unfortunately he's likely also right on most accounts though :(

I'd like to wait to see if this actually affects anything at all before pulling a Theo and forking a project out of spite.

Theo talks a lot about "potential" security problems. There are 50-60 bugs and he'd "bet" that there are 2-3 "potentially exploitable" bugs. Hmmm. Just in case we've forgot how Theo deals with "potentially exploitable" bugs [coresecurity.com] when they're in his own code:

# 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
# 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
# 2007-03-05: OpenBSD team notified of PoC availability.
# 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.

He downplays them, just like he accuses everyone else of doing. He hates it when people call things vulnerabilities when they don't have PoC code (and even when they do), but he's happy to spread FUD about other products without any evidence that anything is exploitable.


Getting back to the problem itself. This is a problem in the MMU, a "show stopper", "buggy as hell", they "scare the hell" out of him. But hasn't Core 2 been out for a while now? Hasn't anyone noticed these terrible bugs? Where are all the reports of misbehaving programs and crashes that should have appeared since Core 2's release 11 months ago?

More likely Theo is leaping at the opportunity to spread FUD about a company that isn't sharing information with him. All processors have bugs; they're incredibly complicated devices. AMD has them, IBM has them, Atmel has them, etc. But they're rarely very serious, they rarely actually affect anything in remotely realistic scenarios.
Until Theo, or anyone, can actually show that these bugs are dangerous and are going to do some damage in a realistic scenario why should we care?

What is Theo adding to this anyway? Intel released the errata to everyone, Theo isn't exposing anything. Theo chimes in with how he's quivering with fear, how they could "potentially be exploitable", and how he "bets" Intel has more errata that they're not telling him.
Raving lunatics like Theo are totally counter productive. How does he expect Intel to respond? "Thanks for telling your flock not to buy our processors, now here are those detailed driver specifications you've been bugging us for!"

Lots of issues

[flyingfsck]

Stack problems, memory management problems, interrupt problems and so on. Many of these bugs will not cause an immediate exception or crash but may look like software bugs, for example a stack problem causing a return to the wrong address.

I guess MS Windows users will simply blame Microsoft's sloppy code, when it isn't even their fault...

Re:Yay AMD

[TheRaven64]

On the ARM front, the most interesting stuff is coming from Samsung, who have ported Xen to ARM. The really neat thing about this is that it allows you to carry your entire 'desktop' state around with you, then live-migrate it to your TV when you get home. They currently have some experimental work doing 'partial migration,' where the VM remains resident on both systems, and acts like a single system image cluster, allowing you to run different processes on the different machines, then fold them all up and take them with you later.

Re:How hard is it to get right?

[Anonymous Coward]

So, where is the bug report? Did the corporation of GP decide to contact developers? Perhaps spending a few dollars to get a bug fixed? I didn't read anything about that, while that is what FOSS is about: co-operation. If it were an individual, I'd be less inclined to say this, but once you start bragging "about your customers" I guess it must be worth a lot to to get this fixed...