Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Theo de Raadt Details Intel Core 2 Bugs

kdawson posted more than 7 years ago | from the linux-last-in-line dept.

Intel 442

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

cancel ×

442 comments

Yay AMD (4, Funny)

delt0r (999393) | more than 7 years ago | (#19674651)

Thank God I got a AMD this time around.

Re:Yay AMD (5, Informative)

BosstonesOwn (794949) | more than 7 years ago | (#19674703)

I don't think that is a good thing either. It looks like AMD may be doing this as well.

(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).

Re:Yay AMD (2, Insightful)

delt0r (999393) | more than 7 years ago | (#19674835)

He said they are getting less and less helpfull. Which is not the same as "just as bad".

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.

Re:Yay AMD (1)

operato (782224) | more than 7 years ago | (#19674943)

start buying some via cpu's. we'll get a third at some stage.

Re:Yay AMD (3, Informative)

vadim_t (324782) | more than 7 years ago | (#19674963)

Well, there's VIA as well, althought their stuff left a lot to be desired the last time I checked it out. Their mini-ITX stuff had potential -- small, low power usage, REALLY good crypto and video acceleration to compensate for the slow CPU. Unfortunately when I tried a Nehemiah board, it was very unstable.

Re:Yay AMD (1)

delt0r (999393) | more than 7 years ago | (#19675137)

Well VIA are not really performance CPU's. There are more for application that are size/power sensitive IIRC. The idea of using the phrase "two party system" is that voting for the independants does not get them into power. That is we have a market dominated by just 2 players. Really just one major player with a significant other.

We just got a 150 000 euro cluster from IBM. The options were intel or AMD.

Re:Yay AMD (0)

Anonymous Coward | more than 7 years ago | (#19675213)

Got a few mini-itx from via: none is really convincing; all run OpenBSD now (and fine) as their Windows/Linux claims
were countered (on paper and in reality) by (processor) incompatibilities. Announcements are another factor.

Re:Yay AMD (2, Funny)

Intron (870560) | more than 7 years ago | (#19674981)

Why x86? You write a lot of code in machine language? Ever hear of Java?

Re:Yay AMD (1)

delt0r (999393) | more than 7 years ago | (#19675053)

I program 98% in java. What cost/performance option is there that not x86? The Cells are comming, but how well do the JIT perform on them? There was the PowerPC etc with apple. But now thats gone too.

Re:Yay AMD (1)

Intron (870560) | more than 7 years ago | (#19675307)

Over half the programming being done is not x86-specific. It's either for Sun, IBM, embedded or in a machine-independent language like Java or perl. The main thing preventing use on the desktop of non-x86 CPUs is Windows. And the only reason that x86 is cheaper is the volume due to desktop use.

Re:Yay AMD (5, Informative)

TheRaven64 (641858) | more than 7 years ago | (#19675311)

SPARC is doing very well for certain categories of workload, although mainly web-app types at the moment. Most computers sold these days have some form of ARM chip[1], which is a nice, low-power architecture, but lacks floating point. This isn't a huge problem, since a lot of ARM designs (particularly those from TI) have a DSP on die which can seriously out-perform a general purpose CPU for a lot of FPU-heavy workloads.

For general-purpose usage, the most interesting design I've seen recently is the PWRficient from P.A. Semi. It's a nice dual-core 64-bit PowerPC, with low power usage, similar performance to IBM's PowerPC 970 series. It has a lot of nice stuff on-die (crypto, a really shiny DMA architecture, etc).

For a complete round-up of current alternatives, take a look at this article [informit.com] and the next two in the series.


[1] They are generally marketed as 'cell phones' or similar, rather than 'computers'.

Re:Yay AMD (1)

Etyenne (4915) | more than 7 years ago | (#19674709)

From the TFA:

(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).

Yay indeed.

Re:Yay AMD (1)

cab15625 (710956) | more than 7 years ago | (#19674719)

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

Re:Yay AMD (5, Interesting)

Idaho (12907) | more than 7 years ago | (#19674765)

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 :(

Theo says... (0)

Anonymous Coward | more than 7 years ago | (#19674895)

(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).
While this news does force me to rethink my intention to purchase a Core Duo MacBook Pro from Apple, because that's a lot of money to pay for a system inherently insecure thanks to Intel's negligence, I suppose one shouldn't go running to hug an AMD logo in an "us versus them" obsession when the latest offerings from Sunnyvale have hidden flaws (and not just the CPUs).

Re:Theo says... (1, Informative)

Anonymous Coward | more than 7 years ago | (#19675111)

Every CPU released for probably as long as you've known about computers has had an errata sheet on it. If you want to stop buying CPUs with errata... well... your computing days are over.

Intel chips (4, Funny)

supersnail (106701) | more than 7 years ago | (#19674653)

.. not intel compatable.

Ask for your money back folks!

How hard is it to get right? (2, Interesting)

Junior J. Junior III (192702) | more than 7 years ago | (#19674657)

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?

Re:How hard is it to get right? (1)

delt0r (999393) | more than 7 years ago | (#19674753)

This is all true, and AMD have had problems in the past. Though it does seem to be more of a Intel problem. There bugs tend to be worse and intel tend to be worse at letting everyone know. IMO anyway.

Don't get me wrong, I have had my fair share of intel machines. I *almost* got a duo this time around. But a store special on a AMD X2 was just too good to pass up.

Re:How hard is it to get right? (4, Informative)

ardor (673957) | more than 7 years ago | (#19674781)

Actually we are talking about VHDL. The "million transistors" argument is just as appropiate as saying "software is so large, it has so many ones and zeros". Development does not happen at this low stage.

Re:How hard is it to get right? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19674913)

Do you seriously think they code the ENTIRE chip in VHDL? Get real.
Stop spitting out acronyms you don't know much about.

Re:How hard is it to get right? (2, Insightful)

herrkaiser (980315) | more than 7 years ago | (#19675129)

They probably have a VHDL or Verilog for most parts (if not all) of the chip. But that doesn't stop to make things by hand. I bet that most of the parts of the chip (especially the critical ones) are made by hand. I don't know how GP got insightful.

Re:How hard is it to get right? (5, Insightful)

imgod2u (812837) | more than 7 years ago | (#19675069)

Yes and no. There are limitations to HDL's (and Intel, last I heard, was all Verilog). For one, it is *very* difficult, if not impossible in certain situations, to describe asynchronous signals. With something as complicated as a microprocessor that is so aggressively designed for both power and speed, I would guess that they didn't go with a completely synchronous design (hell, no one does anymore). Locally synchronous, globally asynchronous design has been in use for a while. It helps when you want to be able to shut off, or slow down, only parts of the chip that aren't being used very much.

It is not possible to describe such things (let alone voltage islands, voltage scaling) in an HDL language and they must either be a special feature built into synthesis (with an extra set of constraints) or done by hand at the transistor/gate level.

Then there's the point of verification. Every software release since about the mid-1990's has almost been immediately followed by patches. Just because it's "1's and 0's" does not mean that it doesn't get harder to detect corner cases as complexity grows. And it's much more difficult if you have to simulate on a cycle-accurate model (boot-up for an operating system, in simulation, would take a day on a nice cluster on something as big as the Core 2).

Then there's post-synthesis/layout issues. Timing analysis do best on sequential logic (completely synchronous). When you throw in clock gating, multiple voltage islands, dynamic voltage scaling (meaning dynamic gate delays), not to mention the plethora of other techniques that those folks might be doing, what you see in simulation at the RTL level will not match what you see in reality. First rule they ever teach in any ASIC design class is never trust simulation.

The point is that abstraction, like how it's "vhdl", does not mean that it's not difficult to get right and even sometimes impossible to be certain.

Re:How hard is it to get right? (1)

herrkaiser (980315) | more than 7 years ago | (#19675167)

Also, there are some parts that are not even digital anymore. Because of the very high speed, they should work like digital ports, but they are actually some analog circuitry.

Re:How hard is it to get right? (1)

RichMan (8097) | more than 7 years ago | (#19675317)

The problem is that they are releasing buggy hardware.

They should be respinning and correcting. Also their design process should adapt and catch these bugs next time.

What this speaks to is a rapid hardware churn and release cycle without proper testing and validation.

Re:How hard is it to get right? (0)

Anonymous Coward | more than 7 years ago | (#19675197)

what does Very High Density Lipo-proteins have to do with this?

Re:How hard is it to get right? (2, Interesting)

supersnail (106701) | more than 7 years ago | (#19674803)

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.

Re:How hard is it to get right? (4, Funny)

SatanicPuppy (611928) | more than 7 years ago | (#19674823)

What is a bug but an undocumented feature?

A hundred million transistors (1)

TapeCutter (624760) | more than 7 years ago | (#19674957)

Three words....Black box testing [wikipedia.org] .

Re:A hundred million transistors (0)

Anonymous Coward | more than 7 years ago | (#19675039)

Many things can't be testing with blackbox testing dumbass. Most notably, a new system of doing things that makes code vulnerable if it doesn't do it the new way (like is the case with many of those errata).

Re:A hundred million transistors (1)

azrider (918631) | more than 7 years ago | (#19675163)

Three words....Black box testing.

Three more words (sans link):

BLACK BOX VOTING

Re:How hard is it to get right? (3, Interesting)

Zontar_Thing_From_Ve (949321) | more than 7 years ago | (#19674983)

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:How hard is it to get right? (3, Insightful)

liquidpele (663430) | more than 7 years ago | (#19675119)

So... Why can't you just go back to freebsd 6.1?
In all seriousness though, being a fanboy should not have anything to do with it. The business and your customers are what should matter, so go with the OS that provides the best stability/features for the customer. Since most customers want different things, most people provide a wide range of OS choices anyway.

Re:How hard is it to get right? (4, Informative)

TheGratefulNet (143330) | more than 7 years ago | (#19675233)

AMD64 doesn't like FreeBSD 6.2 at all

% uname -a
FreeBSD myhost.grateful.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon May 28 09:52:28 PDT 2007 me@myhost.grateful.net:/usr/obj/usr/src/sys/AMD64 i386

granted, I'm using 32bit mode - but I've been running 6.2 for as long as its been out and my 'always on' freebsd box. what issues are you seeing? this is my production box - but I don't see any problems with bsd. in fact, I also have 6.2 running with an old amd64 3000+ that was a mobile chip and had to have cpufreq enabled just to move it off its default 800mhz and up to the 2.mumble ghz that its supposed to clock at. works fine.

I have seen some hardware devices not behave well but often its not a well designed piece of hardware or its just not meant for server style loads (cheap consumer onboard sata sometimes times out and usb2.0 always times out if you give it enough load).

I can't speak to amd64 USING 64bit mode, but 32bit mode works as well as (or better) than linux on headless style computing.

Re:How hard is it to get right? (1)

suv4x4 (956391) | more than 7 years ago | (#19675141)

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?

It's not about size, it's about messiness. The current x86 architecture is just hacks upon hacks. Various CPU modes slapped on top in each generation. Commands abstracted into other commands or translated to RISC commands. Certain commands running on parallel and other not, complex branch prediction techniques.

And what is x64 if not yet one more layer of hacks upon x86.

All of this creates a prospect of having buggier and buggier chips in time because we can't get rid of the x86 legacy. It's not unlike the struggles Microsoft is having while trying to retain backwards compatibility of its OS.

Just like biological organisms eventually age, leave offspring and die, the technology cycle proceeds in the same fashion. This means we'll be seeing virtualizations and translations and hacks that keep compatibility to one turning point where someone will come up with a simple fast stable and clean solution and overtake the old market leaders.

Re:How hard is it to get right? (2, Insightful)

cyfer2000 (548592) | more than 7 years ago | (#19675229)

most of those transistors are used to make cache. Assume there are 4MiB L2 cache, roughly 33.5 million bit, Intel uses 6 transistors per bit design, that's about 200 million transistors. There are also several million transistors used for the L1 cache. I remember there are no more than 300 million transistors on Conroe chip, so we are talking about tens of transistors for code execution now. And there are sill a lot of transistors used to locate the cache, decode...

Summary sucks, someone please provide better one (2, Interesting)

Blahbooboo3 (874492) | more than 7 years ago | (#19674683)

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:Summary sucks, someone please provide better on (4, Informative)

Aladrin (926209) | more than 7 years ago | (#19674757)

Sure:

Some of the bugs are so dangerous that it doesn't matter WHAT operating system you're running, code could be written that could attack the entire system. It would still be OS-specific code, but since the exploit is in the hardware, it's a LOT harder to prevent the attack, if it's even possible.

Some of the bugs are unfixable, as well. (I assume they mean without physcially replacing the chip with a 'fixed' one that doesn't exist yet.)

Re:Summary sucks, someone please provide better on (1)

0123456 (636235) | more than 7 years ago | (#19674873)

"Some of the bugs are so dangerous that it doesn't matter WHAT operating system you're running, code could be written that could attack the entire system."

Indeed. For example, 'rm -rf ~'

I can see that a number of these bugs could potentially be exploited by evil code running on your machine. But if you have evil code running on your machine, you're already in deep crap.

Re:Summary sucks, someone please provide better on (3, Interesting)

vadim_t (324782) | more than 7 years ago | (#19675003)

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.

Re:Summary sucks, someone please provide better on (2, Informative)

0123456 (636235) | more than 7 years ago | (#19675093)

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

True, but that depends on how easily they could be exploited in the real world, rather than in the theoretical world. From what I remember, one was about incorrect behaviour when your code runs off the end of a 4GB boundary; certainly that might be exploitable, but not on any system which can't run >4GB of code.

I skimmed through the bugs which the author said really scared him and didn't see anything that looked easy to exploit from a user program. Yes, if you want total security on your system then they'd be scary, but if it's almost impossible to exploit then it really doesn't matter to anyone much outside the most secret parts of the government (and, even then, bribing people would probably be an easier way of stealing secrets).

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

You're assuming that AMD chips are any better.

Re:Summary sucks, someone please provide better on (1)

Corporate Troll (537873) | more than 7 years ago | (#19675335)

Yes, if you want total security on your system then they'd be scary

We're talking about Theo here.... Total security is what the OpenBSD project aims for.

Re:Summary sucks, someone please provide better on (1)

DrSkwid (118965) | more than 7 years ago | (#19675071)

There's the added bonus of the possibility that the source code would look benign but compile it to buggy machine code and it turns belligerent.

VHDL for voting machines (4, Insightful)

martyros (588782) | more than 7 years ago | (#19675225)

So perhaps the NY law requiring software for voting machines to be held in escrow should include the chip layout as well...

Re:Summary sucks, someone please provide better on (5, Informative)

swillden (191260) | more than 7 years ago | (#19675249)

Some of the bugs are so dangerous that it doesn't matter WHAT operating system you're running, code could be written that could attack the entire system. It would still be OS-specific code, but since the exploit is in the hardware, it's a LOT harder to prevent the attack, if it's even possible.

Here's a little more detail, based on my (very incomplete) understanding of the issues:

It appears that Intel has made changes to the way the memory management unit in the processor works, plus there are also some bugs that affect memory management. So what does that mean?

  • Theo mentions changes in how TLB flushes must be handled. Translation Lookaside Buffers (TLBs) are tables where operating systems cache information used to quickly determine what physical memory page corresponds to a given virtual memory page. Each running process has it's own address space (meaning the data at address, say, 1000, is different for each process) and operating systems have to be able to quickly translate these virtual addresses to addresses within the physically-available RAM. The authoritative data on the mapping is in a set of data structures called the "page table", but the processors provide a mechanism for creating and managing TLBs which act as a high-performance cache of part of the page table data. Failing to properly flush the TLBs during a context switch (putting one process to sleep and activating another) might result in the new process' virtual memory mapping being done incorrectly. From a security perspective, this could give one process access to memory owned by another.
  • Another issue mentioned is the possibility that No-Execute bits may be ignored. The OS can set the No-Execute (NX) bit on a page of memory that it knows to be pure data that should not be executed. The processor will refuse to execute code from any memory page with NX set. This makes most buffer overflow attacks impossible, because the normal buffer overflow attack involves getting a bit of malicious code shoved into a stack-based buffer as well as overflowing the buffer to overwrite a return address so that the CPU will jump to and execute the malicious code. Obviously, if the processor sometimes ignores NX bits, the buffer overflow attacks become possible again.
  • Theo also mentions possibly-ignored Write-Protect (WP) bits. The OS can mark memory pages as read-only. This is used for all sorts of things related to security. One of the biggest is preventing processes from writing to the memory in which shared libraries are loaded. If my process could overwrite, say, the C library code implementing "printf", other processes that call this function would execute my code. Some of them will be running as root, so I can execute code with root permissions. Modern operating systems do lots of data-sharing between processes, some of it completely non-writable, other parts of it "copy on write". Copy-on-write pages are implemented by setting the WP bit and then catching the page fault generated by the CPU when a process tries to write the page. The fault handler quickly copies the page in question, allows the write to hit the copy, and reswizzles the page table so the virtual page of the writing process points to the new copy. WP bits being ignored would also break this, so lots of cases where data is "opportunistically" shared would become really and truly shared, allowing one process to corrupt data used by another.

There are other issues as well... but these are a good sample, and should give an idea of what kind of bad stuff these CPU bugs/changes can make possible.

Re:Summary sucks, someone please provide better on (5, Funny)

Hurga (265993) | more than 7 years ago | (#19674773)

can someone at slashdot please provide an "english" translation of the problems and how dangerous they are to normal users?

"We don't have the complete picture yet, but things look bad"

Hanno

translation (3, Funny)

circletimessquare (444983) | more than 7 years ago | (#19674885)

the computer thingamajibs don't do things right and the computer nerds are all upset about it. best not to click on ANYTHING until 2009

Re:Summary sucks, someone please provide better on (0)

Anonymous Coward | more than 7 years ago | (#19674927)

im sure it says "news for nerds" round here somewhere ... LEARN.

Re:Summary sucks, someone please provide better on (2, Informative)

ioshhdflwuegfh (1067182) | more than 7 years ago | (#19675205)

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?
The second link [geek.com] in the article, containing brief descriptions of bugs, might be useful, although perhaps still quite technical. One bug that is perhaps easy to communicate to the "normal user" is AE30, where the bug might cause some software running on Core Duo during the dehibernation to reload data from the wrong memory location. It's labeled as "potentially catastrophic", and I imagine that after the wrong reload, more or less anything can happen: some program crashing, OS crashing, to, who knows, maybe even some exploits can be programmed to use this bug...

Good stuff. (4, Insightful)

AltGrendel (175092) | more than 7 years ago | (#19674685)

I always find Mr. De Raadt's comments an interesting read. He's like a geek version of Harlan Ellison.

Re:Good stuff. (5, Informative)

Lisandro (799651) | more than 7 years ago | (#19674915)

Same here. The guy might seem like a bit of an asshole sometimes, but he surely knows what he's talking about. Some of the things he points out are plain unbelievable:

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.


It will be interesting to see what Intel has to say about this.

Re:Good stuff. (4, Funny)

suv4x4 (956391) | more than 7 years ago | (#19675241)

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.

It will be interesting to see what Intel has to say about this.


Yea! Damn, where's the Intel Opinion Center exactly when you need it!

Intentional? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19674687)

There seem to be intentional modifications in there. Could that be a backdoor and a good reason for countries like China to develop their own CPUs?

Re:Intentional? (5, Insightful)

Slashcrap (869349) | more than 7 years ago | (#19674987)

There seem to be intentional modifications in there.

Unprovable conjecture. Why would Intel make this public if they were?

Could that be a backdoor and a good reason for countries like China to develop their own CPUs?

Are you the same freak that posted on KernelTrap about how every CPU since the 486 has been bugged by the NSA and can be monitored by satellites? If so, please carry out the recommended course of action that I detailed to you on that occasion. Namely that you set fire to yourself outside the UN building in order to draw attention to your cause. Thanks in advance.

how do they fix it? (0)

Anonymous Coward | more than 7 years ago | (#19674695)

do they just submit a patch to intel for the hardware? can i upgrade my intel cpu to newer firmware? hopefully i dont need a floppy drive cause i dont have one!! haha.

Patches (3, Insightful)

suv4x4 (956391) | more than 7 years ago | (#19674723)

outstanding, fixed, and non-fixable Core 2 bugs

Well, in these days of fast-paced business, business at the blink of an eye, at the speed of light, at the speed of spooky action at distance kinda speed, it's normal that companies would release products prematurely and then patch later.

Thankfully, software is very easy to patch post-release.

Now, the only thing left to do, is someone tell Intel that they're selling hardware.

Re:Patches (3, Informative)

Jeff DeMaagd (2015) | more than 7 years ago | (#19675091)

Now, the only thing left to do, is someone tell Intel that they're selling hardware.

Hardware has had built-in firmware/software for as long as I remember. BIOS is software. Microcode for even consumer CPUs has been done for as long as I remember, Pentium II had it. Apparently, the 8086 had microcode-based instructions.

Re:Patches (2, Informative)

suv4x4 (956391) | more than 7 years ago | (#19675193)

Hardware has had built-in firmware/software for as long as I remember. BIOS is software. Microcode for even consumer CPUs has been done for as long as I remember, Pentium II had it. Apparently, the 8086 had microcode-based instructions.

Don't confuse microcode with firmware. Two different things. Microsode isn't intrinsically updateable, and may be placed in a read-only memory block.

Re:Patches (1)

jefu (53450) | more than 7 years ago | (#19675255)

According to Andy Grove (Intel co-founder) "Hardware is nothing but frozen software.", so they are selling software, "frozen software".

WHY WHY (0, Troll)

zakeria (1031430) | more than 7 years ago | (#19674749)

is this news! almost all Intel CPU's have microcode releases why is this any different?

Re:WHY WHY (1)

SatanicPuppy (611928) | more than 7 years ago | (#19674805)

It's a series of significant hardware bugs, some of which are exploitable from userland, which may or may not be easily correctable with a bios patch.

That is why it's news. I've been watching this since it broke, and I'm interested in this thread. I doubt I'm the only one.

Re:WHY WHY (1)

zakeria (1031430) | more than 7 years ago | (#19674863)

but why do we not see mentions to other Intel bugs where the same is true.. is this the first time userland code and exploit these bugs I think not!

Time for RISC? (2, Insightful)

644bd346996 (1012333) | more than 7 years ago | (#19674795)

For years, the x86 instruction set has been implemented on top of RISC cores. That microcode layer has been getting thicker over the years, and now it seems that it may be too complex to be reliably dealt with. I wonder if this means that we should toss out that x86 layer and deal just with the high-performance, straightforward RISC core.

Re:Time for RISC? (4, Insightful)

Viv (54519) | more than 7 years ago | (#19674931)

The market resoundingly rejected that idea when Intel tried to hoist IA64 on it.

IA 64 is not a RISC chip (0)

Anonymous Coward | more than 7 years ago | (#19675019)

IA64 is an EPIC [wikipedia.org] chip, which is kind of VLIW offshoot.

Re:Time for RISC? (0)

Anonymous Coward | more than 7 years ago | (#19675051)

Response to the architecture it self was fairly strong. The difficulty was in getting the zoning permission to locate the required nuclear power station in your datacenter.

Re:Time for RISC? (1)

BosstonesOwn (794949) | more than 7 years ago | (#19675123)

Because of the huge hit it took to move to that platform. The costs for most business operations were to high.

They would need to do it sort of like what is going on with x64 at the moment. Slowly transfer it over and maybe run an emulation layer on the os. The procs are plenty fast enough to take a small hit on performance.

Re:Time for RISC? (2, Informative)

Slashcrap (869349) | more than 7 years ago | (#19675055)

I wonder if this means that we should toss out that x86 layer and deal just with the high-performance, straightforward RISC core.

Did you know that one of the main reasons that x86 outperforms any similarly specified RISC chip is because those horribly inelegant, variable length x86 instructions allow for considerably higher code density than RISC?

Elegant does not necessarily equal faster or better, no matter how much you might want it to.

Shock Felt Round the World (4, Interesting)

N8F8 (4562) | more than 7 years ago | (#19674797)

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:Shock Felt Round the World (-1, Offtopic)

Overzeetop (214511) | more than 7 years ago | (#19674861)

Oh, don't worry, the government will write a check and your grandchildren will pay for it. Sure, there'll be a lot of teeth gnashing and such, but yuo gotta do what you gotta do, and the government isn't really in the business of doing things efficiently. Lest you feel I'm being overly harsh, I spent almost a decade with NASA and have seen the process up close, then a couple years on black programs. I now work in industry. It's almost frightening how inefficient such a large organization can be.

Well... (0, Insightful)

Anonymous Coward | more than 7 years ago | (#19674809)

I have to say that his had swayed my choice in motherboard and CPU. I was going to order the parts to build a Core 2 Duo based system this week, but after reading this I'm going to find an Athlon 64 X2 in a comparable price range.

What's the point of a speed boost if Intel is breaking x86 architecture (Intentionally? Hahaha!) and leaving your PC open to rape on basically *any* OS?

intel issues (3, Interesting)

artjunk (1088603) | more than 7 years ago | (#19674837)

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:intel issues (1)

gilesjuk (604902) | more than 7 years ago | (#19674883)

Why would it be a problem for Mac users? there are literally a handful of viruses and malware for the Mac.

I doubt these bugs will cause problems for many end users, it is those using servers that will be worried. But the code has to get onto the box first.

Re:intel issues (2, Informative)

artjunk (1088603) | more than 7 years ago | (#19674933)

From what I gather from the article, it's irrelevant what OS you use - as some of these issues are at the lower level (under/before the OS). And, since all newer macs are Intel Core Duo's, I think this could be be an issue for them as well.

Re:intel issues (1)

another_fanboy (987962) | more than 7 years ago | (#19675047)

it's irrelevant what OS you use
The exploit is at the hardware level, but the program targeting the exploit would be written for the individual OS. Not to say macs are in any way better, just that they have a smaller chance of being targeted than windows/*nix.

Re:intel issues (1)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#19675139)

From what I gather from the article, it's irrelevant what OS you use...

I don't think that is quite true. In order to execute one of these exploits, you need to get something running on the box and that means it has a binary that will run on your OS. Once that happens, you're rooted with no security measures in software able to do anything about it. To be useful, however, the OS will still have to be taken into account at this point as well.

That is not to say no one will write a cross platform worm or a mac specific exploit for this, since it is as vulnerable (maybe more so) than Windows. This is a problem for Mac users, but maybe not quite as large of a problem as you're implying.

AI65 Thermal Interrupt is not generated... (1)

farker haiku (883529) | more than 7 years ago | (#19674905)

AI65. A Thermal Interrupt is Not Generated when the Current Temperature
is Invalid
Problem: When the DTS (Digital Thermal Sensor) crosses one of its programmed
thresholds it generates an interrupt and logs the event
(IA32_THERM_STATUS MSR (019Ch) bits [9,7]). Due to this erratum, if the
DTS reaches an invalid temperature (as indicated IA32_THERM_STATUS MSR
bit[31]) it does not generate an interrupt even if one of the programmed
thresholds is crossed and the corresponding log bits become set.
Implication: When the temperature reaches an invalid temperature the CPU does not
generate a Thermal interrupt even if a programmed threshold is crossed.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.


I don't see why this is an issue. The Intel Desktop temperature monitor doesn't even work on my E6600, so how can it detect an invalid temperature? In other news, alternative temperature monitor programs (like speedfan [almico.com] )work, while the official intel one does not.

Re:AI65 Thermal Interrupt is not generated... (1)

farker haiku (883529) | more than 7 years ago | (#19674929)

please allow me to correct myself before I get jumped on. the fault lies in my intel motherboard (D975xbx2), using the intel chip E6600.

Re:AI65 Thermal Interrupt is not generated... (1)

Speare (84249) | more than 7 years ago | (#19675063)

To turn to the usual car analogy tactic:

I don't see why this is an issue. The Intel Desktop temperature monitor doesn't even work on my E6600, so how can it detect an invalid temperature?

I don't see why this is an issue. The burnt-out low-oil lamp on my dashboard doesn't even work on my car, so how can the oil pump detect an invalid oil level?

If the input is working right, then a high temperature reading should trigger an interrupt to warn the OS that it should back off for a while. If the input isn't working right, perhaps it's just making up values, most of which are valid (10C, 80C, 345C, etc.) but maybe sometimes those made-up values are not valid (#NAN, #INF). Now, I don't know squat about this situation, but this is what it sounds like to me. Maybe if it thinks it has *ever* seen a #NAN, it will *never* trigger an interrupt again.

Potential DoS exploit: even on a good processor with a good sensor, make it think it has seen a #NAN, then work the processor until it locks up without any warning or notice given to the OS.

Re:AI65 Thermal Interrupt is not generated... (1)

farker haiku (883529) | more than 7 years ago | (#19675117)

Whoooosh. That was the sound of a joke flying over your head.

Am I the only one... (1)

Xest (935314) | more than 7 years ago | (#19675215)

...wondering WTF an invalid temperature is?

Surely a temperature is always going to be valid unless these processors only support an extremely small set of possible temperature values?

Anyone have more insight into what an invalid temperature might be and how it might be caused?

Others? (1)

drxenos (573895) | more than 7 years ago | (#19674921)

I just bought a laptop with a Core 2, but its not one of this specific processors. Does that (necessarily) mean mine does not have these issues? I think its a later model.

No Intel Niether Amd what to buy VIA ? (1)

denisbergeron (197036) | more than 7 years ago | (#19674923)

Before, you can buy Mac for the Open arhitecture of the Power! Now, what can we buy ?

Read to the end of TFA !

(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).

UGH!! Just bought Core 2 (2, Funny)

pygmy_jesus (1071948) | more than 7 years ago | (#19674953)

I've stuck with AMD for over 6 years, but after all the talk about how they fell off, plus the OC ability of Intel, I just put together a core2 system! You see what happens when you fuck a stranger in the ass, Larry?!?!

Well... (1)

ardor (673957) | more than 7 years ago | (#19675023)

and now? Everyone should trash their Core 2's? I for one have neither the money nor the incentive to do this. Its a good thing De Raadt highlights these very serious issues, but unfortunately it comes too late.

Microcode (1)

pathological liar (659969) | more than 7 years ago | (#19675027)

... so how many of these are fixed by recent microcode updates? How many CAN be fixed by microcode updates?

So how long before we start seeing... (0, Offtopic)

clickety6 (141178) | more than 7 years ago | (#19675033)

... Intel Core 2 processors embedded everywhere... paper weights, key ring fobs, geek jewellery, ...

(I still have my nice Pentium key ring from the last big chip snafu!)

Hogwash! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19675057)

I was hoping for a bit better from an accomplished programmer.

Where is the user space code that hits these bugs?
Where are the detailed descriptions?

I don't think this particular firebrand could use any of the bugs, on an completely unpatched processor, to get his way into ring0.

I doubt he could even hang the machine

Without code, this is just sour grapes over his other issues with documentation from intel.

Quantum effects? (5, Interesting)

DFDumont (19326) | more than 7 years ago | (#19675077)

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?

Intel: The Microsoft of Hardware? (0)

Anonymous Coward | more than 7 years ago | (#19675079)

"We will correct all bugs with our Core 2 SP1 pack"

Rush to conquer? (3, Interesting)

Applekid (993327) | more than 7 years ago | (#19675085)

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.

Insider view of the latest x86 bugs (0)

Anonymous Coward | more than 7 years ago | (#19675109)

I recently interned at the Haifa branch of the Intel's Israeli R&D center. It's the branch that originally developed the Nehemia core technology. I posted some of my experiences working there in my blog [ouch.co.il] , and I reveal some (unclassified!) details of their development process.
Posted anonymously for obvious reasons..

Re:Insider view of the latest x86 bugs (0)

Anonymous Coward | more than 7 years ago | (#19675303)

Posted anonymously for obvious reasons..
...but linked to a blog?

Silent + urgent = deadly (1)

jihadist (1088389) | more than 7 years ago | (#19675155)

Of course it's exploitable. Otherwise, no "urgent" but "silent" patch. Then again, on a chip of this complexity, until they create an AI to hack-test it, there will be errata.

$ per exploit (1)

Gothmolly (148874) | more than 7 years ago | (#19675201)

So someone like Andre Hedrick, or Linus, or Alan Cox, or Theo, could write an exploit for this that would root a box, but any script kiddie or Russian hacker could write a CSS or JPEG hack for IE that roots the box. Which is easier? Which is more likely?

The braking system in my car could catastrophically fail, or a soccer mom could mow me down with an SUV. I trust the brakes, I don't necessarily trust the soccer moms. It's all about risk. It might be technically interesting to read Theo's analysis, but the sky is not falling.

Linus doesn't think it's a big deal. (5, Informative)

davebert (98040) | more than 7 years ago | (#19675235)

Link [realworldtech.com]

Better armor leads to improved weapons (1)

duffbeer703 (177751) | more than 7 years ago | (#19675251)

Plate armor was great until someone came up with the longbow. Large bastions/fortresses ruled warfare until mobile artillery became more practical.

There's a sense that operating systems are getting better with security, so it's no suprise that people are starting to look at hardware.

If these flaws are srious enough (0)

Anonymous Coward | more than 7 years ago | (#19675291)

Who knows, Intel may be forced to do a recall/replace thing.

Product recall (1)

digitalderbs (718388) | more than 7 years ago | (#19675315)

Could this be a case for a product recall? A compromised OS could be considered a safety risk, and they're shipping a defective product. Some of these issues seem quite serious, requiring special treatment for bugged CPUs in the code.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...