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