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.'"
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
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.
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.
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?
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.
If information wants to be free, why does my internet connection cost so much?
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.
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.
Comment removed based on user account deletion
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.
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.
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...
There is a spark in every single flame bait point.
You'd be surprised - there are all sorts of gotchas on different platforms... different OS library support, different word length, different byte orders, alignment issues, etc. then at the OS level you have path separators (/,\,.,:,whatever plus existence of drives eg SYS$SYSTEM:[00000] is a path on VMS, C:\ is a path on Windows - and not all filesystems support paths in the sense Unix does anyway, Character set assumptions (you can't assume the platform supports utf8, or even ASCII), Case sensitivity, Character set sensitivity, etc.
/OS specific - until you've been through the pain of translating to an entirely different OS (HPUX is fun, VMS is even more fun, or for *lots* of fun try OS/360) it's difficult to know - and that goes for any language, including Java (which mitigates some of the issues but by no means all of them.. not to mention the jvm isn't available on many platforms).
No code (except assembler) is CPU specific.. you can compile an average (well written) C app on pretty much anything with a C compiler, but it's often unknowningly architecture
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
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.
Verilog is perfectly capable of describing designs at the gate level. Just last semester I designed a simple 16-bit RISC processor at the gate level (with the exception of flip-flops, given to us as black boxes) using Verilog.
Verilog is a huge language. While it may be the case that some of its constructs assume a clock (I can't say- I worked with a tiny subset), the language itself does not assume a clock and is capable of dealing with asynchronous circuits.
"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
Well, considering Linus was writing an OS kernel before Theo, and up to a few years ago was earning his living /designing/ CPUs, I think I'll go by his analysis, thank you.
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.
Actually, Itanium was a wildly successful product. Mere rumors of Itanium's capabilities were sufficient to kill DEC Alpha, drive SGI/MIPS out of the high end processor market and disrupt SPARC and PA-RISC development programs. Intel virtually eliminated the threat of competitive RISC architectures for years with the announcement of Itanium.
(Another company that works like that is Microsoft, which is why they keep churning out such bad software.)
To much the same effect.
I think they are coming from different angles.
If you read the post, Linus's opinion is that all cpus have errata, and from the point of view of Linux, these errata don't impact linux that much because they've already designed their internal systems to deal with contingencies like these, because Linus believes erratas are just going to go up as we make more cpu's.
Theo, on the other hand, is coming at it from a "black-hat" point of view. Given the processor, he's thinking how people can compromise the cpu on a hardware level.
They have differing POV's, and it's not really "who's right", but "who's priorities do you align yourself with."
In normal use, as the core 2 has already been proved in general use for about a year already, these errata are easy to shrug off. If it crashes, just reboot it. If it corrupts your data, just get it from backup.
However, if you're using it in a military / hard crypto setting, there might be concerns.