Slashdot Mirror
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.'"
Thank God I got a AMD this time around.
If information wants to be free, why does my internet connection cost so much?
.. not intel compatable.
Ask for your money back folks!
Old COBOL programmers never die. They just code in C.
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?
You see? You see? Your stupid minds! Stupid! Stupid!
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!
I always find Mr. De Raadt's comments an interesting read. He's like a geek version of Harlan Ellison.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
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.
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.
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.)
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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
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.
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.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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?
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.
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!
"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.
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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).
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)work, while the official intel one does not.
Your sig(k) has been stolen. There is a puff of smoke!
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.
Anonymous Cowards suck.
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).
Ceci n'est pas une Signature !
im sure it says "news for nerds" round here somewhere ... LEARN.
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?!?!
Three words....Black box testing.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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.
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.
IA64 is an EPIC chip, which is kind of VLIW offshoot.
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.
This sig does not contain any SCO code.
... so how many of these are fixed by recent microcode updates? How many CAN be fixed by microcode updates?
(I still have my nice Pentium key ring from the last big chip snafu!)
----------------------------------- My Other Sig Is Hilarious -----------------------------------
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.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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
Given that definition every transistor's source, drain and gate are nanoparticles. And we expect them to behave classically why?
"We will correct all bugs with our Core 2 SP1 pack"
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.
More Twoson than Cupertino
"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.
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, and I reveal some (unclassified!) details of their development process.
Posted anonymously for obvious reasons..
Comment removed based on user account deletion
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.
Anti-Globalism
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.
I want to delete my account but Slashdot doesn't allow it.
...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?
So perhaps the NY law requiring software for voting machines to be held in escrow should include the chip layout as well...
TCP: Why the Internet is full of SYN.
Link
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?
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
Who knows, Intel may be forced to do a recall/replace thing.
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.
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.
You're assuming that AMD chips are any better. Without any security notices to suggest otherwise, that's a pretty reasonable assumption to make isn't it?
"Without any security notices to suggest otherwise, that's a pretty reasonable assumption to make isn't it?"
Why? Do AMD even release full errata lists for their chips?
Every chip of this complexity has bugs and probably lots of them. If Theo had said that he's checked the AMD list and it didn't have any exploitable bugs then that would be a reason to consider them, but without even knowing what bugs they might have, why would you assume they're any safer?
Maybe Intel should stop releasing these lists and then no-one would even know about them.
Theo posts a link to a GIF of the errata, wherein AE4 and AE11 appear to describe the same bug (REP MOVS across a memory type boundary) but one says SHOW STOPPER while the other says possible effect on performance, no data loss or corruption.
'twould be nice if the errata were more consistent. I'll have to check thePDF.
Infuriate left and right
The first Pentium had a floating point bug. Maybe they're working too closely with Microsoft? (I kid! I kid! Put down that flamethrower!) Any way, here are a few Pentium jokes I dug up. If only the Core 2 bugs were all floating point erroirs we could recycle all of these old jokes to Core 2 jokes!
Q: How many Pentium designers does it take to screw in a light bulb?
A: 1.99904274017, but that's close enough for non-technical people.
Q: What do you get when you cross a Pentium PC with a research grant?
A: A mad scientist.
Q: What's another name for the "Intel Inside" sticker they put on Pentiums?
A: The warning label.
Q: What do you call a series of FDIV instructions on a Pentium?
A1: Successive approximations.
A2: A random number generator.
Q: Complete the following word analogy: Add is to Subtract as Multiply is to:
1) Divide
2) ROUND
3) RANDOM
4) On a Pentium, all of the above
A: Number 4.
Q: What algorithm did Intel use in the Pentium's floating point divider?
A: "Life is like a box of chocolates." (Source: F. Gump of Intel)
Q: Why didn't Intel call the Pentium the 586?
A: Because they added 486 and 100 on the first Pentium and got 585.999983605.
Q: According to Intel, the Pentium conforms to the IEEE standards 754
and 854 for floating point arithmetic. If you fly in aircraft
designed using a Pentium, what is the correct pronunciation of "IEEE"?
A: Aaaaaaaiiiiiiiiieeeeeeeeeeeee!
Q: Did you hear about the new "morning after" pill being developed as a replacement for RU-486???
A: Its called RU-Pentium. It causes the embryo to not divide correctly.
TOP TEN NEW INTEL SLOGANS FOR THE PENTIUM:
9.9999973251 It's a FLAW, Dammit, not a Bug
8.9999163362 It's Close Enough, We Say So
7.9999414610 Nearly 300 Correct Opcodes
6.9999831538 You Don't Need to Know What's Inside
5.9999835137 Redefining the PC -- and Mathematics As Well
4.9999999021 We Fixed It, Really
3.9998245917 Division Considered Harmful
2.9991523619 Why Do You Think They Call It *Floating* Point?
1.9999103517 We're Looking for a Few Good Flaws
0.9999999998 The Errata Inside
THE TOP TEN REASONS TO BUY A PENTIUM MACHINE:
10. Your current computer is too accurate
9. You want to get into the guinness book as "owner of most expensive paperweight"
8. Math errors add zest to life
7. You need an alibi for the I.R.S.
6. You want to see what all the fuss is about
5. You've always wondered what it would be like to be a plaintiff
4. The "intel inside" logo matches your decor perfectly
3. You no longer have to worry about cpu overheating
2. You got a great deal from JPL
1. It'll probably work
Thank you, thank you, I'll be here all week. Remember to tip the bartender. Lets see, 20% of... divide by...
I don't know why Theo posted that link, because it is about the Core, not the Core 2. They are two completely different micro-architectures. The Core was a slightly tweaked Pentium M (which is basically a P6 with extra vector instructions and the NetBurst branch predictor), while the Core 2 is a completely new micro-architecture. If you compare the errata in the two links, you will see that they are quite different.
I am TheRaven on Soylent News
You know those shirts from thinkgeek.com that threaten to replace you with a small shell script? Turns out there might be something to it for Slashdot editors.
Pretty good is actually pretty bad.
http://marc.info/?l=openbsd-misc&m=11830201643010
and control computers remotely.
* Monitor and control (filter) the network traffic - before/under the
running operatingsystem
* sending out patches to computers - even if they are turned off.
* Control, upgrade, change, add and remove software
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.)
What worries me most is; with software, you can supply a fixed version to customers for the cost of a CD and a postage stamp (or less), with hardware it's slighly more expensive and thus slightly less likely to ever happen.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The interesting thing about this is that software protection vendors and crackers now have more tricks, especially concerning permissions, the bad news is that debugging is also messed up.
Shared hosts should run VMs anyways. The trick then is when the instructions are executed natively. If you can root the VM program that'd be cool.
Tom
Someday, I'll have a real sig.
the AMT (Advanced Management Technology) is the truly frightening bit. Big Brother visits your computer:
6 &w=2
A Swedish ASIC designer explains:
http://strombergson.com/kryptoblog/?p=311
(A rough) translation:
http://marc.info/?l=openbsd-misc&m=11830201643010
Chris
So Buddha walks into a pizza parlor and says: "Hey, make me one with everything."
Do most processors have long lists of problems released some time after the processor's debut? The specification update from Intel lists 105 specific problems.
Single-user systems would not be affected.
Except in the case that you don't trust some software and run it with a non-administrator account to be safe against hijacking of your system.
These CPU bugs may allow malware to get around limitations of the user account it is running on. Thus making an otherwise very sensible precaution useless. The same goes for things like Vista's UAC, if the malware can hack into the OS itself thanks to a CPU bug.
C - the footgun of programming languages
PI just bought a PC with an Intel CPU, in fact, this is the first PC I've owned with an intel CPU in 8 years Been building my own AMD computers since that time. But it's hard to build a UPPC so I got the new Samsung Q1U.
8 .htm
I was under the impression that the A110 series processor in it was a Core2 derivative, but the Intel site states it is a Pentium M derivative.
http://www.intel.com/design/mobile/datashts/31690
My gut feeling is that it has inherited deigns from both (since Core 2 is a Pentium M derivative).
So does it have a serious bug too? (that we haven't been told about yet)
Taking the argument from the Windows vs. OSX debates, does this mean that if Intel have more desktops in our homes the hackers would target Intel's CPU bugs before AMD's ?
And I look forward to upgrading my 248s to 275s on my birthday.
This is my sig.
My UltraSPARC boxes just seemed to be running better after hearing this news. :)
Just out of curiosity, how would one exploit these bugs from user space? Are we talking an attacker can compromise a remote machine? e.g. an apache/php or ssh connection through a buffer overflow? Or does an attacker need local executable access, and if so, can any executable be potentially used to compromise the system, or would they need a specially crafted binary?
And how would this effect a system running advanced security, like grsecurity, PaX or SELinux? Theo mentioned that a potential buffer overflow could bypass a no-exec, or write protected memory space, but would address space layout randomization help to control that?
I wonder if they'll respond the same way as they did to with the FDIV bug (i.e. replace the chips upon request).
Granted, that screwed up a lot more without active exploitation.
I just read Slashdot for the articles.
Speaking of mistakes that reach production....I should have hit "preview".
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
We've had holes in our OS's since... umm... always - I think when we used paper we didn't have holes... except for when we were using the paper made for 3 ring binders.
:)
So what are we left with - just another hole (heh, thats a name of a piercing shop where I live) that exploiters will try to exploit. And then what? The AV companies will do their best (like they always have or haven't) done.
OS's have holes, software has holes, so in this case, do what is smart. Throw up a firewall running a 5 meg version of linux on a 386 box
Looking over the errata sheet, it seems the behavior when these bugs are tripped is not actually fully known. In most cases it's just "unpredictable behavior." De Raadt and the OpenBSD people generally treat "unpredictable behavior" as a possible security hole without first producing a proof-of-concept exploit (regardless of whether it turns out to actually be exploitable).
(IANAL)
"You're everywhere. You're omnivorous."
Is there any available list of WHICH processors are affected?
Are we talking ALL Core 2 Duo chips, of ALL varieties, including mobile?
What other chips are involved? (Personally, I find the whole genealogy if Intel chips very very hard to follow).
I wonder about some of the comments in the "Workaround" sections. Most of the time they weasel and say "no workaround yet". More likely, no workaround is possible in many cases. Then with some of the user-land problems, like REP MOVSB acting up, they say "BIOS can fix". Huh? How could the BIOS fix a broken REP MOVSB? I can see the BIOS being able to patch interrupt related bugs, but a straight instruction? About the only conceivable way would be to have the BIOS load special microcode to emulate the REP MOVSB. But many of the bugs involve what they call the "fast" REP MOVSB which sounds like its done by hardware.
Surely "getting root" on the box would require the OS to actually behave in a logical way in response to a "CPU exploit". If the OS has no visibility of a hardware-level failure isn't it more likely that remote exploitation of a CPU exploit - if it were possible - would simply cause a unrecoverable system error?
Obviously forcing a box offline would be equivalent to a DoS..
About 10 hours ago I put down a deposit on having an Intel Core 2 Duo based computer built for me so this is a bit late!
I chose Intel (Core 2 Duo CPU and 965G motherboard) because of the open video drivers they release (and I enjoy reading about them on planet.freedesktop.org). Hopefully these CPU bugs are just something that is theoretically scary but won't end up posing practical problems for me as a user.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I hope so, as I very very recently bought a Core 2 chip to use on my main machine at home. I'm not holding my breath, though.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Anyone whose tried to get more than a single IDE cdrom drive and serial ATA 2 drives working on a core 2 system at the same time, has probably seen just how buggy core 2 can be. Intermittent/random OS failures, the hard-drives fail randomly (even SATA2 ones), etc. - and that was consistent on 3 motherboards, with 5 different hard drives, even when IDE-sata adaptors or a PCI-IDE card were used. Not only that, but some HD's are outright incompatable with some core2 motherboards.
Theres no excuse for this unreliability, and especially the lack of information. There should have been warnings/more information ON THE BOX, so that consumers dont have to do tons of research just to make sure they're buying a product that will work PROPERLY (or work with their existing hardware). Isnt that already required by law? Mayby someone should start a class-action lawsuit or something, just to get the message across.
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.
I wrapped my CPU in tinfoil to prevent NSA spying, but it stopped working. Goddamn NSA! I guess it doesn't work when the signal from their secret moonbase is blocked.
Another scary bug (perhaps the scariest, since it appears to be the one that most reliably/repeatably occurs) is AI88: Microcode Updates Performed During VMX Non-root Operation Could Result in Unexpected Behavior.
From what the errata says, unless the host software has specifically disallowed access to parts of the MSR, a VMX guest/non-root system could reload the CPU microcode.
This leads to a whole universe of complicated data theft/code execution/etc. exploits that will probably never be created due to their complexity. However, it also leads to a very, very, very simple DoS/crash exploit (load some bad microcode, crash the CPU).
x86 afaik has never been implemented on a RISC architecture outside of anything other than a lab context. It's CISC that is the primary core for x86.
t ml
http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.h
Could that be a backdoor and a good reason for countries like China to develop their own CPUs?
China will use these backdoors like anyone else, why would they bother to invent their own?
Friends don't help friends install M$ junk.
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...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Surely "getting root" on the box would require the OS to actually behave in a logical way in response to a "CPU exploit".
Essentially the aim of such exploits is usually to get your code to be run with privilages it should not have had.
some examples:
all modern operating systems use one copy of shared libraries in memory for all apps that use the library (not doing so would be very wastefull of both memory and cache). If a process can bypass the write protect on that memory it can force other processes to run its code some of those will be running as root.
If your code finds a way to flip the CPU into kernel mode without jumping into the OS then it has the run of all memory and hardware on the system. Once you have that it shouldn't be too hard to find the process tables and change your processes user ID to root.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Because in order for a privilige escalation bug to work there must be an untrusted user that is allowed to run some code in the first place. That is why this bug is more of an issue for Linux/BSD than Macs as most Macs are single user systems.
"Come on people, move along, nothing to see here".
Presumably AE6 is a reverse-compatibility feature to allow OS/2 1.0 to run its DOS box?
Truly history doth repeat itself.
Thank GOODNESS apple switched to intel chips.
Nothing like a monopoly, and a monoculture, to breed innovation and a robust information infrastructure!
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
If you are using paravirtualisation, then it uses exactly the same protection mechansims as a normal kernel, and so you gain no protection from this kind of exploit. If you are using hardware-assisted virtualisation, then take a look at the errata list; a few related to VMX mode. If you are using binary re-writing, then expect to pay a speed penalty.
I am TheRaven on Soylent News
"Hasn't anyone noticed these terrible bugs?"
Apparently they have, and now we know too.
Look, I know Theo-bashing is a traditional bit of fun, so I hate to rain on your parade. But you should keep in mind that the OpenBSD team is uniquely (or nearly so) positioned to discover and publicize the security implications this sort of flaw. The whole project is security oriented; they don't accept "binary blobs" into security-sensitive roles, which means they look more closely at hardware than most; they operate in a very transparent manner; their user base is supportive of any security-related moves by the devs; their installed base is heavy in security-sensitive roles; and the project is notorious for not giving a damn about political considerations.
"But they're rarely very serious, they rarely actually affect anything in remotely realistic scenarios."
OpenBSD is heavily used in the perimeter security role, and in security-sensitive roles generally. As its OS security gets better, OpenBSD's sensitivity to hardware security flaws gets higher. If there's an architectural flaw that the OS can't cover, OpenBSD's user base needs to know that so they can evaluate their overall security and spec hardware accordingly.
Almost no one else needs to worry about hardware exploits in Core 2 as much as OpenBSD does, because almost every other OS for general-purpose hardware has easier exploit paths. For instance, I'm not worried about this flaw on my home iMac, because my iMac isn't in a security-sensitive role. If an attacker wants my home data, it'd be easier for the attacker to simply break in and steal the whole box.
"How does he expect Intel to respond?"
Like the professionals they are, I'd think.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
When we reach the 4nm process, then our electrons will begin bleeding through the insulation. Will be fun to see what the computing industry does then. Or what Intel does when they hit 45nm (the limit to the photolithography process); AMD has a license with IBM for Immersion Lithography which will push them past the 45nm mark.
Would allow Israel to perform Cyberwarfare on unsuspecting opponents. Another reason not to allow foreign entities to be involved in the development of parts that could be used in our defense industry. Of course, this by no means says anything about Israel. Any country with many enemies could do the same given the opportunity.
See the portions in this page, where others here speak of "copy on write" functionality...
6 3&cid=19675249
If you do not understand what this is, or how it works? Look it up, that, & memory mapped files.
It is about shared data between processes & making private copies a particular app uses, as WRITE ONLY to that particular process.
Shared data is one area that I can definitely see being exploited (SQLServer 2005 for instance? Uses this heavily doing db snapshots (a recovery/reliability mechanism, & databases are definite targets for industrial espionage/power/money because information? Really is, power!)
APK
P.S.=> Up above on this page, this gent gives a GREAT overview of this, see his post:
http://hardware.slashdot.org/comments.pl?sid=2426
swillden is his name, & he does a GOOD job of it, especially for someone saying he has an "incomplete understanding of the issues", imo @ least, he does well because he stated that especially (modesty imo, because he hits on exactly what I feel would be targetted & exploited, & I give an example of what I would target above, SQLServer 2005 use of copy on write during DB Snapshots especially, for data alteration, OR theft)... apk
Modern "80x86" processors actually have a RISC core emulating 80x86 CISC instructions. That can't possibly be efficient: there are some occasions when you don't need every bit of an 80x86 instruction to happen (for instance, ADC sets the carry flag, but the next instruction may not care about the state of the carry flag). Although the "interpreter" -- because that's what it really is -- might well be able to optimise out some microinstructions on-the-fly, it almost certainly isn't looking far enough ahead to be certain about that.
Native code running directly on the underlying RISC core, if there was a way to do it, ought to be faster than emulated 80x86 code. A lot faster, if the compiler is good.
Really, the only reason 80x86 (which really is a truly horrible design, mostly cruft and bodges upon bodges) is still popular at all, is to allow Microsoft to keep the Source Code of Windows secret. The BSDs and Linux don't have any such requirement -- the Source Code is readily available, and they can and do run on almost any processor architecture. AMD's 64-bit architecture is a little cleaner but still held back by the need to implement 32-bit instructions.
Think what we could do with something like ARM, but built in straight 64-bit (i.e. ditch byte addressing and deal strictly in 64-bit words) and going back to Furber and Wilson's original concepts which eschewed complications such as hardware multiply and divide precisely because software implementations can be quicker for shorter word lengths (multiplying two 8-bit values requires only 8 additions, but a 64-bit hardware multiplier will always do 64 anyway). If 64 bits really is too much for one instruction, then maybe squeeze in two 32-bit instructions that then (attempt to) execute in parallel (so must be writing into different registers, unless the condition fields -- with ARM, every instruction is conditional, though there are "AL" and "NV" conditions that execute always and never respectively -- are such that both won't be satisfied together). This would need two logic matrices, but they could share a common register file.
Je fume. Tu fumes. Nous fûmes!
Anyone know where I can get a SPARC laptop?
a) how does working around these bugs affect Intel Core Duo's performance?
b) I WAS thinking about buying a Core Duo so this information comes just in time.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
Am I the only one to think that the author should have paused for two seconds before blasting this out. Not due to any security issues, just at the end of his rant, he decided to take shots at Intel and AMD "Becoming less helpful by the day" Now if you were the chap at intel that did his best to get stuff sorted for Linux/BSD/Whatever oss project, going out on a limb to help, you would think "Fu*k you Theo" and be a lot less inclined to help and devote more support time to support contracts that potentially earn money.
http://www.writeitfor.us - Writing IT for the IT generation.
Ok, lets look at some of these.
/dev/io or memory-mapped bus space can exploit it. So e.g. something like XOrg, but not the typical user program. Worse case seems to be a system freeze. Still, this is something to be concerned about.
AI65 - Thermal interrupt does not occur if DTS reaches an invalid temperature. What the hell is an invalid temperature? A disconnected sensor or something? It doesn't sound like something a userland thermal-generating loop can exploit but the errata is not detailed enough to know for sure.
AI79 - REP/STO in specific situation may cause the processor to hang. BIOS patchable. The errata mentions an uncacheable memory store. If this is a pre-requisit then only user programs with access to
AI43 - Concurrent MP writes to non-dirty page may result in unpredictable behavior. This one is extremely serious. It effects any threaded program and possibly even programs which are no threaded. This would cause me to not purchase the cpu. It says that a BIOS workaround is possible (aka microcode update).
AI39 - Cache access request from one core hitting a modified line in the L1 cache of another core may cause unpredictable system behavior. What the hell? Are they out of their minds? This is a big-time show stopper. It says it can be fixed with the BIOS (aka microcode update). I sure hope so.
AI90 - Page access bit may be set prior to signaling a code segment limit fault. This one is pretty serious. This cannot occur on most operating systems because the code segment is set to be unlimited and access is governed solely by the page tables. In 64 bit mode emulating 32 bit operation the problem might occur if a bit of code wraps the segment. There are possibly issues in other emulation modes, such as VM86 mode. The effect of setting the page accessed bit will not make a page accessible that was not previously unaccessible, but it will result in unexpected modifications to the page table page and numerous operating systems may free such pages to the page-zerod page list under the assumption that they cleaned the page out when in fact there may be a page table entry with the access bit set (meaning the page wasn't completely zerod when freed). That could cause problems.
AI99 - Updating code page directory attributes without tlb invalidation may result in improper handling of a page fault exception. This one doesn't look too serious, it just means the wrong exception will be taken first, meaning that the OS will probably seg-fault the program. If the OS corrects the issue and retries, the correct exception will be taken on retry. All BSDs that I know of handle page fault exceptions generically and will not be effected. Of greater concern is what sort of modifications to a page directory entry now require TLB invalidations? On FreeBSD and DragonFly, and I assume most BSDs and probably Linux too, page directory entries usually transition between only two states and a TLB invalidation is made when a page directory entry is invalidated, so they wouldn't be effected by this bug.
That's actually a bad article about a real issue. A better article is here.
Intel's AMT technology puts special purpose hardware in the network controller which recognizes UDP and TCP packets on ports 16992, 16993, 16994, and 16995. This is completely independent of the operating system. Various system administration functions can be performed. Anybody can inventory the machine and read its ID. Other functions, like power off/on, reboot, user disable (disables keyboard/mouse/on-off switch) and remote disk I/O require a password or crypto key.
This has been around for a while; the previous version was called IPMI, Intelligent Platform Management Interface. It talked UDP only. AMT also talks TCP and HTTP; there's a whole protocol stack in the network controller now just for this. This was originally a server farm management system, but now it's on desktops, too. If HTTP mode is enabled, you can control the machine from a web browser via port 16692.
It even works while the computer is "turned off"; it's part of "wake on LAN" functionality.
Supposedly, there is no valid default password or key, and the feature is supposedly off by default. But if any software ever enables this, you're 0wned.
The computer manufacturer can preload management keys. "An OEM may supply platforms with a PID-PPS pair already written to the Intel AMT Flash memory.", according to Intel. If a vendor does that, they 0wn your computer. Something to watch for. AMT can also be enabled from the Intel Management BIOS extension screen. (Password: "admin", it says in the manual.)
The normal way AMT keys get loaded in a corporate environment is that you plug in a USB key with a special file ("setup.bin") and power cycle the machine. The machine then tries to connect to the mothership on port 9971, doing a DNS lookup for "ProvisionServer" if no IP address was specified.
If you don't want AMT enabled, here's how to disable it:, "Intel AMT is returned to Factory Mode by selecting the Unprovision option on the BIOS Extension menu or by disabling Intel AMT from the BIOS extension Manageability Feature Selection."
The whole AMT system is reasonably designed; it even has Kerberos authentication. But it's so powerful and so hidden that if it's ever enabled, it's worse than a root kit. Even reinstalling the OS won't help.
Here's Intel's technical info about AMT.
I bought a duo core e6600, new MB, new everything actually. Now whenever I play MP3's or video it will randomly slow down for a second. My friend has the same issue, but with a different brand of motherboard. He is running an e6400 though. updated drivers do not fix this. using a sound card does not fix this. BIOS updates do not fix this. I do notice that when I get the slow down I see a 10% jump in CPU usage on only one of the CPU Usage History graphs from within Windows Task manager.
d uo_errata__2006_01_21__full.gif
After reading this:
http://www.geek.com/images/geeknews/2006Jan/core_
I still can't tell if this is an issue with the processor, but I'm betting it is. And if it is does Intel have anything in place for the consumer to fix these issues?
'mmmmmmmmm.... forbidden donut'
So it sounds like someone was designing CPUs like I see some people designing software. They don't think through all the edge cases, but instead rely on testing to point them all out to be fixed. Except, they obviously didn't have sufficient testing in place to catch all of these edge cases. OUCH!
BTW, without going too far down this road, but did a different, perhaps newer, team have a good hand in this processor's implementation?
I am planning on buying a new desktop this summer and am currently looking at the Core 2 Q6600. (Hmm... next price drop is July 22nd, probably waiting until then.) So I have two questions:
Centralization breaks the internet.
Typically I have found Intels to be more reliable in the server market than AMD's. This was especially true with the capicators blowing up and the nvidia/AMD chipset bug.
I have seen winXP blue screen multiple times on my new core2duo system and I assumed it was microsoft code doing the crash or bad hardware. It happens when I change video modes quickly like open Itunes or Wow. I read the errata and its related to the CPU.
I read Theo's comments about AMDs list getting very big as well.
Are generic x86 cpus' safe any server that requires uptime? Is it time to move on to something more modern and I do not mean Itanium.
Maybe switching back to Risc might be ideal with less instructions which means less things go wrong or Intel's new chip that is VLIW that can do 1 trillion operations per second is the future. Simple multiple cores running in parallel with large loads of cache to share might be more stable and simpler.
http://saveie6.com/
How ironic these bugs are in the processor and Apple now have migrated to all of the Macs to the Intel platform. However there is no processor in the world that has absolutely no bugs in them and the programmers need to program around most of them. The processor manufactures need to tell the programmers of these that know of and have a open forum to allow other people to discuss bugs that they have found.
I still have a fair amount of the Apple PPC systems I wonder if how many bugs does it have.
I love Theo--really. But he should change his name:
Theo de Rant.
I might know what I'm talkin' about, but then again, this is Slashdot...
RISC for RISC's sake is stupid.
All of the supposed upsides to RISC have been thrown aside, using the CISC techniques for performance's sake.
Look at the UltraSPARCs. Or the POWER architecture. Out-of-order execution, write barriers, speculative prefetch, branch predictors, SIMD instruction set extensions, all eating up chip real estate. But they need it to wring the appropriate perfomance out of the chip and keep those ALUs doing meaningful work.
The only thing different between them and X86s is that X86s have a slightly more involved instruction decoding step. (But not by much, and the modern RISC descendants have instruction decoders too.) On the other hand the X86 instruction set has built-in instruction compression which keeps the size of the cache needed for code smaller. Most RISC-derived chips have larger, word sized instructions which demands larger caches.
The one thing that made the 32-bit ISA retarded is that many instructions weren't orthogonal, and you didn't have enough GP registers to play with. That was fixed with x86_64, and you get some speed gains, but it ain't much. And some code is slower just because immediate operands (now 64 bit) are larger and eat up cache.
And this isn't a problem unique to Intel. Everyone goes through this, everyone uses microcode.
UltraSPARC needs microcode too. It needs it to implement the IA. (You know, task switching, page fault handling, etc.) It just so happens that Intel rushed the Core and there's bugs in that stuff, bugs that needed to be fixed ASAP. If it happened to Sun it's not such a big deal, they just release a patch for the Solaris kernel that takes care of it (either through OS workarounds or microcode patching, or both).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Ok, big deal. All just because Microsoft decided to push microcode update thru windows update.
/proc/cpuinfo | grep bug' if you don't believe me.
Any, _ANY_* CPU manufactured under the sun for quite a few years already has had some issues in the silicon. Some of those are more publicly announced, some not, but regardless almost any of them has had the issues fixed by means of pushing CPU software update with the help of the bios. Ugly, yes, why do you think, your BIOS [update] is the size it is, but it works and generally there is no fuss about it.
Also, quite a few operating systems know about the most critical/unfixable bugs and work around them. Simple as that, see 'cat
nonissue.
And all that fuss just because M$ decided that they could actually try to push it forwards as it probably was affecting windows. Not everyone updates bios on a daily basis.
I don't think people on this thread have the correct conceptual understanding of the bugs reported. For the Core architecture, Intel sets design targets for performance and power consumption and time to market to kick AMD's backside, which they have done successfully. In order to achieve power consumption targets, they almost certainly designed Core with fewer pipeline stages than the Pentium IV, while requiring the complexity level in each pipeline stage to rise to achieve a higher IPC. They also decided to do some fancy things with the L2 cache to enhance dual core performance levels. I'm quite certain that Intel engineers working on various design problems discovered they couldn't meet their functionality, power consumption, circuit area, and timing constraints that the business objectives for Core mandated. Then after a lot of head scratching, the engineer cleverly discovers that if they change the logical requirements in very subtle ways that some clever circuit does meet those targets. Do the subtle logical changes violate the x86 functional requirements? The supervisory team meets to hash this out. The proposed design passes all the simulator compliance tests. Some engineer speaks up "well, in theory, it could matter in some situation, depending on a lot of complex things". That engineer is soon shouted down with a lot of hard headed business rational about kicking AMD's butt. The Core Duo design project races to conclusion and achieves all its business objectives. The chips sell like hotcakes. Then slowly it begins to trickle out that all of these subtle logic design short-cuts actually do matter in various situations both imagined and not imagined. Surpise: some of them can't be fixed in software or with microcode or BIOS updates even in principle. Oh crap! And we already sold so many of these and made such a fabulous profit, whatever are we going to do now?
Many of these errata are not mysterious problems with the implementation process. They are cleverly conceived deliberate tweaks to the logical requirements that enabled Intel to make the chip faster and sooner and cheaper to achieve a short term business advantage at unknown cost to the end consumer at the end of the day. Intel was desperate for a design victory over AMD. They got one. And this was the cost: ten of millions of end customers now owning systems that can't be properly secured by any reasonable means.
Everything to do with the Q965 chipset.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
How about microkernels?
Are they better at surviving these attacks?
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
I am in EXACTLY the same boat dude! Finished the build yesterday! Dont worry about this CPU SNAFU man, the dude abides... the dude abides...
When I was 18 and still living at home, my family had some guests from out of town. One of the guests, Martin, was in town for the (1978?) SciFi convention in Lake Tahoe. The night before my friend's father was to leave, I was up late. I had the phone in my room (we had a 30' extension... man, those days before cordless were fun!) and it rang at about, oh, 2am. Now, this never happened in our house. Ever. I answered it and said hello. What I got back stunned me. "Is Martin there?" "Yeah, but, like, he and everyone else in the house are asleep... it's 2am." "Please tell him I'm on the phone." "OK, and who are you?" "Harlan Ellison." "OK, I'll tell him."
At that point I had read a lot of his stuff, but I was too chicken to say so.
The next day I got to drive Martin to Oakland so he could hitch a ride with Robert Silverberg. But, that's a another, very interesting story...
If it crashes, just reboot it.
Clearly you're a Windows user, without a clue about the rest of the world.
I guess you'll be totally happy when the server of the MMOG you're playing crashes, or when your credit card transactions abort during withdrawal, or when your payments get lost, or your online ordering mysteriously fails.
"Just reboot it" is the most moronic thing I've heard for a long time.
If someone out there thinks they have the necessary skills (say, you can write your own bootloader if you wanted to) and wants to take on this issue, drop me an email, I have a few ideas how you might go about it.
How we know is more important than what we know.
AI91. Update of Attribute Bits on Page Directories without Immediate TLB
Shootdown May Cause Unexpected Processor Behavior.
That's the one that Microsoft was worried about. The problem doesn't affect Linux as it doesn't reduce the privilege of upper-level paging structures without flushing all of the affected TLB entries.
from what I gather...
..outside of the range of permitted writing for the process
the MMU simply does not operate as specified
The way the cpu handles memory accesses is borked, or to put it another way:
Deer vey dee zpu verks ees borkin borked.
a write-protect or non-execute bit for a page table entry is ignored
When the cpu is told not to execute the stack, it will anyway.
This program has performed and illegal instruction. Please tell Microsoft about this problem..
All of this is just unbelievable to many of us.
d00d wtf !?
boycott slashdot February 10th - 17th check out: altSlashdot.org
Would it make you really happy if you were responding to a mentally unstable individual who actually went and self-immolated in front of the UN building?
If you keep saying this kind of destructive shit, one day some lunatic will take you up on it. How will you feel then?
How will you feel then?
Like it was bound to happen some time anyway.
I believe that the CPU would return to its original state after being powered down and back up.
You didn't mention that part, but it's worth noting.
It could bring down your box, but it wouldn't brick the hardware.
Still not a Martha Stewart "good thing", though.
If you're a zombie and you know it, bite your friend!
A spammer/spyware writter could just rewrite the MBR to load its microcode.
ALso I wonder if its possible to use this to run windows in a virtual machine and not be able to delete the rootkits these spyware makers are making.
Scary indeed.
http://saveie6.com/
Thank you for your response. You are obviously much smarter than I am and my well considered response has no value in the light of your brilliance.
Better, perhaps, but still about 1/3* of the speed of my Intel Xeon X5365-based system. Who cares if it's correct, so long as it's fast?
*based on Multi-threaded SPECintRate 2006 benchmark for two-socket systems
I use the Suns for structural and computational fluid dynamics analysis of prototype aircraft. Clients aren't particularly picky about speed, and neither am I. We are however, picky about numbers being correct. People aren't fond of airplanes falling out of the sky.
The Pentium and Core processors' huge sales mean that Intel has more debugging resources to throw at debugging the "RISC portion" than most companies have for their entire processor.
Also, you say the "RISC portion" is a false dichotomy, but (even though you were the one who first made that distinction) it's not false at all. There is a separate physical part of the chip that cracks CISC instructions into RISC, and the rest of the chip is a RISC processor. Its a completely valid dichotomy.
The bottom line is, we're both making unfounded claims. If your assertion were true, then there should be some evidence that makers of RISC chips produce fewer errata, all else being equal. If you can find some evidence, I will humbly beg your forgiveness.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I think the word you're looking for is foist.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....