Theo de Raadt Details Intel Core 2 Bugs 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.'"
Yay AMD (Score:4, Funny)
Re:Yay AMD (Score:5, Informative)
by day towards open source operating systems too, perhaps because
their serious errata lists are growing rapidly too).
Re: (Score:3, Insightful)
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 (Score:4, Informative)
Re: (Score:2)
We just got a 150 000 euro cluster from IBM. The options were intel or AMD.
Re: (Score:3, Funny)
Re: (Score:2)
Re:Yay AMD (Score:5, Informative)
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: (Score:3, Interesting)
Re:Yay AMD (Score:4, Funny)
I'll rather take the 16 year old model, please. :-P
Re:Yay AMD (Score:5, Insightful)
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
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
Dam I really think it would be better if we didn't have a "two party system" in the x86 field. A third (or fourth) vendor would be nice. But given the high barrier to entry, its not going to happen anytime soon.
Heck, it doesn't even have to be x86. I don't use anything but open-source software, so I don't really care one bit about the underlying architecture, as long as it performs well. If somebody builds a well-performing, price-competitive mobo/processor combo that I can drop into my current box, and supports USB/SATA/PCI/2D graphics, I'll use it.
ARM, MIPS64, PowerPC, SPARC, whatever works... I imagine there's a large community of open-source users who would similarly jump ship from x86 if there were an alte
Re: (Score:2)
From the TFA:
Yay indeed.
Re:Yay AMD (Score:5, Interesting)
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
Re:Yay AMD (Score:5, Funny)
Re:Yay AMD (Score:5, Interesting)
Unfortunately he's likely also right on most accounts though
Theo talks a lot about "potential" security problems. There are 50-60 bugs and he'd "bet" that there are 2-3 "potentially exploitable" bugs. Hmmm. Just in case we've forgot how Theo deals with "potentially exploitable" bugs [coresecurity.com] when they're in his own code:
# 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
# 2007-03-05: OpenBSD team notified of PoC availability.
# 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
Getting back to the problem itself. This is a problem in the MMU, a "show stopper", "buggy as hell", they "scare the hell" out of him. But hasn't Core 2 been out for a while now? Hasn't anyone noticed these terrible bugs? Where are all the reports of misbehaving programs and crashes that should have appeared since Core 2's release 11 months ago?
More likely Theo is leaping at the opportunity to spread FUD about a company that isn't sharing information with him. All processors have bugs; they're incredibly complicated devices. AMD has them, IBM has them, Atmel has them, etc. But they're rarely very serious, they rarely actually affect anything in remotely realistic scenarios.
Until Theo, or anyone, can actually show that these bugs are dangerous and are going to do some damage in a realistic scenario why should we care?
What is Theo adding to this anyway? Intel released the errata to everyone, Theo isn't exposing anything. Theo chimes in with how he's quivering with fear, how they could "potentially be exploitable", and how he "bets" Intel has more errata that they're not telling him.
Raving lunatics like Theo are totally counter productive. How does he expect Intel to respond? "Thanks for telling your flock not to buy our processors, now here are those detailed driver specifications you've been bugging us for!"
Theo-bashing is so passe. (Score:5, Insightful)
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.
Re:Theo-bashing is so passe. (Score:4, Insightful)
Second; how are they uniquely positioned? Theo read the errata that's public to everyone, and says that he "bets" there may be "potential" security implications. He's in a unique position to troll and spread FUD about a company that doesn't pay attention to OpenBSD, but apparently he's not in a unique position to offer anything new.
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.
This is exactly how Theo wants people to react to this; "now the Core 2 isn't safe", even though his mail contained no substance whatsoever.
Like the professionals they are, I'd think.
Hopefully Intel are more professional than Theo, and will be working on future products and technologies, and finding bugs in existing ones, rather than indulging in empty self righteous flamefests.
Re:Theo-bashing is so passe. (Score:5, Insightful)
So in your clause "Raving lunatics like Theo" you'd like the reader to focus on the fact that he's raving, but the reader should basically ignore that you just happen to mention in passing that you think he's a lunatic?
Right, got it. Thanks for the clarification on that.
"Theo read the errata that's public to everyone, and says that he "bets" there may be "potential" security implications."
Well - and I can only speak for myself here - the fact is that I'm an ignorant fuckwit when it comes to the security implications of Intel's hardware errata. I know just enough to know that I cannot read Intel's chip errata and produce an opinion about the security implications that ihas any statistically-significant superiority to random chance. I'd guess that it is highly likely that well in excess of 95% of the general computer-buying public is similarly ignorant.
However, I'm dead certain that Theo knows a great deal more about secure OS design and the implications of these errata than I do. I'm pretty sure he knows more about it than you do, too. (Nothing personal, but I figure there's probably under five thousand people worldwide who have similar expertise at the moment. Odds are you're not among them.) His track record thus far isn't perfect, but it's really fucking good. So if he says that it's likely that some of the flaws will prove exploitable, I'm willing to provisionally trust his predictive opinion.
And it's not like it'll stop me - or most other security-conscious people - from buying Core 2 machines. It will, however, prevent most or all security-conscious admins from deploying such machines in highly security-sensitive roles until the picture becomes more clear. This is not going to be a huge impact on Core 2 sales, because there already were better hardware solutions than Core 2 for both multi-user server roles and for perimeter security roles. The real problem with these alleged security flaws will be in the laptop and desktop markets, because Core 2 is pre-eminent there. Even so, it would only affect the segment of that market that is security-sensitive... which probably is not a huge portion of that market. (As another commenter said, though, the DoD's tech buyers are probably going to have serious headaches.)
So if Theo's goal is to wound Intel - which I doubt - this is not going to leave a big mark in sales. Theo fails it!
Overall, I don't think your theory holds much water. Sure it's possible that he's just being a dick about it just to spite intel. But it's also possible that his expertise leads him to have genuine concern, and his forthrightness leads him to say it plainly. I, for one, am not willing to bet my network security on the chance that the former possibility contains the whole truth behind this.
Re: (Score:3, Insightful)
Case in point: AI90. Theo claims this is already "exploitable" in some OSes (not his). Okay.. well... What does this exploit look like? Does it ca
Intel chips (Score:5, Funny)
Ask for your money back folks!
How hard is it to get right? (Score:3, Interesting)
Re: (Score:2)
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? (Score:5, Informative)
Re:How hard is it to get right? (Score:5, Insightful)
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: (Score:3, Interesting)
Re: (Score:2, Insightful)
Re: (Score:3, Interesting)
Intel seems to regard these as unpublished improvements rather than bugs.
Re:How hard is it to get right? (Score:5, Funny)
Re:How hard is it to get right? (Score:5, Funny)
Any sufficiently advanced undocumented feature is indistinguishable from a bug. :-)
A hundred million transistors (Score:2)
Re:How hard is it to get right? (Score:4, Interesting)
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.
Comment removed (Score:4, Insightful)
Re:How hard is it to get right? (Score:5, Informative)
% 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? (Score:5, Funny)
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
Wait... this works in Slashdot's text area?
% uname -a
% uname -a
Damn it
Re: (Score:3, Interesting)
I have never seen this but WILL be (now) on the lookout for it. it seems you did find a pretty ugly bug in bsd.
I don't run 64bit mode and I also tend use decent disk i/o cards (3ware in raid1 mode), which I'm led to believe is fully production quality.
(I started using linux in 1995 or so and switched over, almost fully, to freebsd around 1999 or so. I've had almost zero problems with bsd on my production boxes, but these are not multiuser systems - they're LAMP servers (well, minus
Re: (Score:2)
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 par
Re: (Score:3, Insightful)
Summary sucks, someone please provide better one (Score:3, Interesting)
Thanks!
Re:Summary sucks, someone please provide better on (Score:5, Informative)
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: (Score:2)
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 (Score:4, Interesting)
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: (Score:3, Informative)
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
Re: (Score:2)
VHDL for voting machines (Score:5, Insightful)
Re:Summary sucks, someone please provide better on (Score:5, Informative)
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.
Re:Summary sucks, someone please provide better on (Score:4, Informative)
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).
Re: (Score:3, Informative)
Re:Summary sucks, someone please provide better on (Score:5, Funny)
"We don't have the complete picture yet, but things look bad"
Hanno
translation (Score:4, Funny)
Re:Summary sucks, someone please provide better on (Score:2, Informative)
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, may
Re:Summary sucks, someone please provide better on (Score:5, Informative)
Good stuff. (Score:5, Insightful)
Re:Good stuff. (Score:5, Informative)
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. (Score:5, Funny)
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!
What intel had to say: (Score:4, Funny)
Patches (Score:4, Insightful)
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 (Score:4, Informative)
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: (Score:3, Informative)
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: (Score:2)
Time for RISC? (Score:3, Insightful)
Re:Time for RISC? (Score:5, Insightful)
wrong (Score:3, Interesting)
Intel should be developing a conservative RISC processor, an
Re:wrong (Score:5, Insightful)
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.
Re: (Score:3, Informative)
SGI/MIPS canceled two high end CPUs, Beast and Capitan, specifically because of the threat of Itanium. I was there, I saw it happen.
http://news.com.com/Silicon+Graphics+scraps+MIPS+p lans/2100-1001_3-210024.html [com.com]
Compa
Re: (Score:3, Informative)
RISC binaries tend to be larger than CISC binaries. The reason is the complex instruction set, like in the x86 architecture, were made complex to save memory. Most of the common instructions are represented in only one byte, while the rarer instructions can be much much longer. RISC instruction sets, on the other hand, typically have a fixed instruction size for all instructions, and the average instruction length ends up being longer.
While most people have plenty of hard drive space now, and RAM isn't
Re: (Score:2, Informative)
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.
Re: (Score:3, Insightful)
I think the latest Power series will give any Intel CPU a run for it's money as well the latest Sparc.
Code Density is nice since access to main memory is a bottle neck. CISC does have some advantages over RISC just as RISC has some over CISC.
However the x86 as an ISA really does suck. x86-64 is a lot better but it could still be better.
Re:Time for RISC? (Score:4, Informative)
Yes, they will. But those chips are designed with a target price of thousands of dollars and without anywhere near as much concern about heat.
Power has a 128 KB L1 cache (64 KB on Core 2), 4 MB L2 cache per core (4 MB L2 shared on Core 2), and a 32 MB L3 cache (none on Core 2). If you're willing to pay for that, x86 would be a lot faster.
Oh, don't forget that Power chips run really really hot. Hotter than Pentium 4's. The market has made it clear that lower power usage / heat generation is a priority now.
Re:Time for RISC? (Score:4, Interesting)
Shock Felt Round the World (Score:5, Interesting)
Single-user (Score:3, Insightful)
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.
intel issues (Score:3, Interesting)
Re: (Score:2)
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: (Score:2, Informative)
Re: (Score:2)
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
AI65 Thermal Interrupt is not generated... (Score:2)
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 t
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Am I the only one... (Score:2)
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? (Score:2)
No Intel Niether Amd what to buy VIA ? (Score:2)
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).
Well... (Score:2)
Quantum effects? (Score:5, Interesting)
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?
Re: (Score:3, Funny)
That's not a bug. It's a cryptographically secure random number generator!
Rush to conquer? (Score:4, Interesting)
Linus doesn't think it's a big deal. (Score:5, Informative)
Re:Linus doesn't think it's a big deal. (Score:4, Informative)
He may be entirely right, and his experience in CPUs, BIOS vendors and Intel, AMD, etc may mean what he is saying is accurate - but the tone doesn't really sound very professional.
Better armor leads to improved weapons (Score:2)
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.
Old jokes from the Pentium days... (Score:4, Funny)
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...
Scariest post of the thread (Score:4, Informative)
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
The bugs aren't really the scary part, (Score:4, Interesting)
A Swedish ASIC designer explains:
http://strombergson.com/kryptoblog/?p=311 [strombergson.com]
(A rough) translation:
http://marc.info/?l=openbsd-misc&m=11830201643010
AMT - 0wned at the hardware level. (Score:3, Informative)
That's actually a bad article about a real issue. A better article is here. [monstersandcritics.com]
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
Lots of issues (Score:4, Interesting)
I guess MS Windows users will simply blame Microsoft's sloppy code, when it isn't even their fault...
The erratum mentioned (Score:5, Informative)
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.
Re:The erratum mentioned (Score:5, Informative)
AE1 - CPU to memory copy with FST with numeric and null segment exceptions may cause GP faults to be missed and FP linear address mismatch. In otherwords, a segmentation violation will be missed and a write will be allowed to proceed. This will not effect OSs using page tables for protection, which is all OSs. Sounds bad but doesn't sound like it will effect existing OSs
AE2 - Code segment violation may occur if a code stream wraps around a segment. No program does this on purpose, and OSs will just seg-fault the program if it does. The intel errata says it could be exploted by a virus but I don't see how by its current description. Maybe there is something they aren't telling us.
AE3 - POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.
AE4 - REP MOVS in fast string mode continues in that mode when crossing into a page with a different memory type. This means that when crossing over from a cacheable page to an uncacheable page, the I/Os remain cacheable. And vise-versa. This will never happen on purpose so the question is whether it can be exploited in some way, and the answer to that is not that I can see.
AE5 - Memory aliasing with inconsistent dirty and Access bits may cause a processor deadlock. This means a PTE with 'D'irty set but with 'A'ccess not set. FreeBSD and DragonFly always set the A bit when setting the D bit and will not be effected but I don't know about other OSs. This is a very serious bug though.
AE6 - VM bit will be cleared on a double fault exception. Double faults are usual fatal for the whole machine so unless they can occur in an emulation mode (where the double fault is being emulated). Check your OS. FreeBSD and DragonFly do not try to resume after a double fault and do not take faults in VM mode and are not effected.
AE7 - Incompatible write attributes in page table verses MTTR may consolidate to UC. Not a big deal, doesn't happen unless something has been misprogrammed.
AE8 - FXSAVE after FNINIT without an intervening FP instruction may save uninitialized values for FDP and FDS. This isn't an issue unless the data being written represents a security leak of some sort, such as a portion of the state of another program's FP unit. This could be a security issue with regards to one program snooping another program's cryptography. Statistical snooping possible through this sort of mechanic has been shown to be effective in recent years.
AE9 - LTR can result in a system hang. Well, BSDs don't really use LTR all that much and the conditions required just will not happen on BSD or probably linux either. A break point must be set on the cache line containing the descriptor data? Not from userland!
AE10 - Invalid entries in the page directory pointer table register may cause a GP fault. Not an issue.
AE11 - REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type. Not an issue.
AE12 - FP inexact result exception flag may not be set if the #inexactresult occurs in any FPU instruction with certain instructions occuring afterwords. This is a very serious bug that only compilers can work around (and probably won't).
AE13 - IFU/BSU deadlock may cause system hang. I've no idea what IFU and BSU is.
AE14 - MOV with debug register causes a debug exception. Sounds like the worst that happens here is a program seg faults if this condition is hit while the program is being debugged.
AE15 - INIT does not clear global entries in the TLB. Oh, joy. Intel says that BIOS writers would know of thise errata and cod efor it, but insofar as I know this could be an issue when starting up APs.
AE16 - Use of memory aliasing with inconsistent memory type may cause system hang. It shouldn't be possible for this to happen with a modern OS. It means mapping the same physical page of memory with different memory contr
Re: (Score:2)
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:Intentional? (Score:5, Insightful)
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.