“Buried deep in a pile of slashdot comments, Matthew Dillon of DragonFly gives a detailed assessment of the Intel Core bugs. While a lot of news sites and bloggers were quick to dismiss the issue as inflated, Dillon’s comments provide a much closer look at the actual issues.”
its not possible to make a perfect processor (a bug free one). Yes Core 2 arch has its bug, but lets see late August the barely finished barcelona
I remember the many undocumented opcodes on the 6502. Back then, processor bugs were fun, not security problems. You could bitwise AND the Accumulator and X register in one instruction, instead of having to use 4 or five instructions when using the normal AND.
The ultimate hardware bug on the C64 was no doubt the discovery of hardware scrolling, used in Mayhem in Monster Land. How on earth someone found out that messing with $D011 during the IRQ could unlock a feature that was never meant to exist is beyond me.
Awww.. stop it! You’re bring back ssoo many fond memories.. 6502.. beautiful piece of hardware for its time.
Accident, or perhaps secretly shared knowledge not meant for the masses?
Edited 2007-06-30 23:12
This is the worst excuse you hear over and over in discussions whether hardware or software related.
“Yes, we acknowledge a problem, but we’re better than competing product X.”
Anytime you can bring awareness to possible security problems in todays environment is a good thing.
Hi,
AE3 – POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.
This was deleted from the errata in September 2006. I’ve no idea why (it’s rare for this to happen, and I can only assume it was wrong to begin with, and possibly reworded and shifted to a new errata item when more accurate information became available).
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.
Intel manuals have been warning against inconsistant A and D flags for ages. It’s not a serious bug, it’s just a reminder for people that didn’t read the programming manual properly.
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.
This is BS. If the OS initialises the FPU state in any way that could be considered secure when a process is started, then information can’t leak from one process to another (with or without this bug) as the new process would load it’s own full state when FXLOAD is used during (or after) the task switch.
AE21 – The execution disable bit is shared between cores. I’m not sure what this means but Intel seems to think that it compromises an anti-hacker feature. Sounds pretty serious.
This is another “non-event”. An OS either supports execution disable and enables it for all cores, or doesn’t support execution disable and doesn’t enable it for all cores. User-level code can’t control this flag. Virtual machine monitors (e.g. VMX) virtualize the flag.
AE30 – Global pages in the DTLB may not be flushed by RSM instructions before restoring the architectural state from SMRAM. This is catastrophic for any software that uses global pages in SMM mode. It means that no software can use global pages in SMM mode. Operating systems usually do not have any control over what is run in SMM mode so this is a BIOS issue for the most part.
This bug only effects BIOS/SMM code. Global pages are used by OSs to reduce TLB flushes when switching between virtual address spaces, but BIOS/SMM code has no reason to switch between virtual address spaces (and no reason to use global pages).
So in summary, everything that Matthew Dillon thinks might look serious isn’t worth yawning at….
Cheers,
Brendan
>So in summary, everything that Matthew Dillon thinks might look serious isn’t worth yawning at….
If people like Theo de Raadt and Matthew Dillon tell me such things, I believe them. Okay Theo makes some noise, but in the end, there are two people working at superior operating systems and they have lot of experience with such things. Over and out …
If people like Theo de Raadt and Matthew Dillon tell me such things, I believe them. Okay Theo makes some noise, but in the end, there are two people working at superior operating systems and they have lot of experience with such things. Over and out …
…yeah – because MS or the Linux guys have no idea what they’re doing.
I think it depends on how you define what as ‘issues’ – I’ve had a look at Theo’s reply, Matt’s, and Linus.
Theo and Matt see it as very important because of this; programmers aren’t perfect, one (or more) stupid coding mistakes *could* expose their software to these flaws. On very large projects like Windows, *BSD, Linux and so forth, it could be of a major concern.
The issue is whether one should class something as critical if the exploit can be the result of poor programming on the developers part – Theo and Matt maintain it elevates it, Linus and others say that it is up to the programmer to ensure that their software is written correctly.
For me, its important for both sides to be made available; that it isn’t just an accross the board vulnerability. Its up to software companies to keep abreast of erratas relating to CPU’s and more importantly, ensuring that they keep to best programming practices.
If people like Theo de Raadt and Matthew Dillon tell me such things, I believe them… they have lot of experience with such things
Allow me to introduce Mr. Naive and Mr. Savvy, the two orthogonal responses to any event. Mr. Naive thinks the world is changing and that the event at hand is central to these changes. He thinks that the event is unprecedented in either occurrence or significance. It’s either something great that we must all support or something alarming that we must rise up against. Either way, Mr. Naive wants to use the event to elevate himself and his cause.
Mr. Savvy has been down this road before, and he has no reason to believe that this time will be any different. He knows how these things start and how they are resolved. He tells us that this stuff happens all the time, and although it seems troubling, there’s nothing to worry about. Smart people are taking care of it, and everybody else should just keep shopping and using their credit cards. Mr. Savvy wants to deflect responsibility and kill the story.
The truth lies somewhere in between Mr. Naive and Mr. Savvy, but the public won’t be exposed to the nuance of the actual situation. Instead, the issue is framed as a tension between Mr. Naive and Mr. Savvy. “Are CPU bugs going to cause worldwide economic collapse, or is this a perfectly normal part of the computer industry?” This is your standard “Fair and Balanced” frame, and it has been shown to favor Mr. Savvy by a large margin. Mr. Naive comes out bloodied and discredited.
The thing about Mr. Naive is that it doesn’t matter whether he’s right or wrong, or how well he articulates his point. All that matters is whether Mr. Savvy gets a word in edgewise. When Mr. Naive speaks unopposed, we go to war (or stop a war). When Mr. Savvy is allowed to speak, we stay the course. The majority will believe Mr. Savvy until Mr. Naive is proven right in spectacular fashion. By then, of course, it’s too late.
In this case, Mr. Savvy has spoken. Mr. Naive can tell us the sky is falling until he’s blue in the face, and most people will think that everything is fine just the way it is. Only a spectacular errata-based event can bring about a change in how the public views CPU bugs.
[OT] What has been happening in your life, butters? I used to think everyone of your posts was sublime, until around this month..!
Right, because we should trust you, some nobody from nowhere that’s done nothing, over two of the world’s biggest hackers.
“Right, because we should trust you, some nobody from nowhere that’s done nothing, over two of the world’s biggest hackers.”
I was thinking the same thing, tho I would have put it a little more tactfully ;^)
Edited 2007-07-01 00:03
Never found much use for tact, brute force and mobility have always been of more use to me. Hey, I calls ’em like I sees ’em, I’m a whale biologist.
Disclaimer: Not actually a whale biologist.
Well…Linus says it’s not a big deal either. I won’t do you the courtesy of linking to it though since I’m a nobody as well.
Well I thought I’d see what Linus says:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=8055…
Hi,
Right, because we should trust you, some nobody from nowhere that’s done nothing, over two of the world’s biggest hackers.
You don’t have to trust me – Intel has been honest enough to make all the errata information (and all the information you’d need to understand it) freely available for anyone to download and look at.
Simply download the information, learn enough to understand the information, then come back and let me know if anything I posted has technical inaccuracies…
Cheers,
Brendan
When you say “biggest,” do you mean in terms of height, width, or girth?
As in largest contributions to the art. Ever heard of DICE? How about OpenSSH? Either of them rival Bill Joy, Eric Allman, or Marshall Kirk McKusick for the effect they’ve had.
As in largest contributions to the art. Ever heard of DICE? How about OpenSSH? Either of them rival Bill Joy, Eric Allman, or Marshall Kirk McKusick for the effect they’ve had.
An argument should stand on its own merits, not on who delivers it. Appealing to authority does not leave room for rational discussion.
Perhaps, it would probably be nice if the facts alone dictated matters, but that is not so, since not everyone is able to grasp the complexities of the subject.
If she weighs as much as a duck, then, she’s made of wood, which means she’s a witch, and we should burn her! or There is no such thing as a witch.
If your level of understanding is closer to the person making the first argument, it makes more sense to you, those with greater understanding may make statements which you do not instantly comprehend, that does not mean the first statement is correct. If someone has a proven track record of making logical, justified statements, they have earned a level of trust and authority in matters, while a noone from the shadows does not hold any such prestige.
They have earned credibility, not authority. To borrow a quote from an author whose name I can’t remember, “There is no such thing as authority in the realm of ideas.”
No, but that doesn’t make it intellectually-justified to dismiss an argument solely because of the source.
Perhaps, it would probably be nice if the facts alone dictated matters, but that is not so, since not everyone is able to grasp the complexities of the subject.
If you don’t understand the subject, then you shouldn’t judge between opinions on it.
If someone has a proven track record of making logical, justified statements, they have earned a level of trust and authority in matters, while a noone from the shadows does not hold any such prestige.
What you suggest is a common enough logical fallacy that it even has its own fancy Latin name.
The problem is that given an argument made by someone whose expertise you (think you) know and someone whose expertise you are unaware of, there is no way for you to judge, unless you, too, are an expert.
I’ve known Matt since the middle ’90s, for instance, and would not judge him particularly expert on the issue of errata, as he has little experience in new system bringup. But I read his comment critically and the rebuttal also critically, giving each argument equal weight. Matt’s arguments come out as less well supported.
“As in largest contributions to the art. Ever heard of DICE? How about OpenSSH? Either of them rival Bill Joy, Eric Allman, or Marshall Kirk McKusick for the effect they’ve had.”
Huh, not really. Bill Joy wrote a lot of BSD utilities HIMSELF. The only thing that Theo has in common with Joy is that they both lack human skills.
I don’t doubt Theo is a talented programmer, problem is that there are plenty of talented programmers out there… thus he is by no means an authority on computer architecture.
Right, because we should trust you, some nobody from nowhere that’s done nothing, over two of the world’s biggest hackers.
That’s like saying we should always trust Microsoft because they´re the largest software company. Of course what Matthew Dillon and The De Radt says weights more than any comment on osnews but that doesn’t mean we should just trust them blindly. Some of these bugs they point out as serious might be that but still not really a problem.
Of course what Matthew Dillon and The De Radt says weights more than any comment on osnews
They should not. The arguments should weigh entirely on their merits, independent of who made them.
Never confuse notoriety with knowledge, nor expertise in one aspect of computing with expertise in another.
Neither Theo nor Matt have much direct experience in bringing up OSes on processors, and so neither are more qualified judges of hardware errata than anyone here is likely to be.
> Neither Theo nor Matt have much direct experience in bringing up OSes on processors, and so neither are more qualified judges of hardware errata than anyone here is likely to be.
Theo contributed a lot to the SPARC port of NetBSD/OpenBSD; he is a de-facto spokesman for OpenBSD, so he basically says what the other ~80 developers think (including those who do the very low-level work) .
Matt used to design hardware and operating systems from scratch; he is a VM guru (so he has authority to talk on MMUs); he worked on nearly every part of the DragonFlyBSD kernel, including low-level stuff.
They certainly have way more authority to judge hardware errata than you or I.
Theo contributed a lot to the SPARC port of NetBSD/OpenBSD; he is a de-facto spokesman for OpenBSD, so he basically says what the other ~80 developers think (including those who do the very low-level work).
Theo definitely doesn’t poll the developers before he opines.
Matt used to design hardware and operating systems from scratch; he is a VM guru (so he has authority to talk on MMUs); he worked on nearly every part of the DragonFlyBSD kernel, including low-level stuff.
He never designed a processor from scratch, nor, as far as I know, has he ever worked on a processor bringup.
They certainly have way more authority to judge hardware errata than you or I.
The whole point of my comments on this thread is that “authority” is meaningless in discussions like this.
I have been involved in the design of processors from scratch, I have done low level bringup on very complex processors, and I have dealt with far worse errata than those that Theo is complaining about. However, I would not want you to take my word for this.
Theo has offered no arguments to support his claims, only claims. Matt has offered arguments, but others have offered counters. You should forget Matt’s credentials and compare his arguments to those being offered in rebuttal.
If you understand the field, then you will realize that Matt has overreacted in this instance, and Brandon has done a good job of addressing his concerns.
Right, because we should trust you, some nobody from nowhere that’s done nothing, over two of the world’s biggest hackers.
You should not trust or distrust anyone because of who they are, when they are making an argument. You should evaluate the argument and judge it on its own merits.
Matt has a long history of overreacting, as does Theo. Neither of them make a case that the errata here are any worse than in any other widely used processor (nor can they, as they are not, but don’t take my word for it.)
alot of those bugs I think are consider show stopper bugs.
It’s nice that this is still being discussed, but the real followup should be the fact that all the news outlets (perhaps deliberately) missed the point. To quote Henning Brauer:
people just don’t get it.
first, intel provides the microcode updates only to MS and hardware vendors. if you don’t run windows and your hardware vendor does not supply a bios upgrade, you’re doomed. And we all know how good hardware vendors are at suplying updated bioses…
second and more importantly, there updates by intel only fix a FEW of these problems, a LOT are left. there’s some indicators that some of these issues are not microcode fixable. and intel clearly stated that they will not fix some others.
And this is exactly the problem addressed by de Raadt and Dillon.
>the fact that all the news outlets (perhaps deliberately) missed the point
You should just read the corresponding links.
“intel provides the microcode updates only to MS and hardware vendors.”
http://urbanmyth.org/microcode/
It would be nice if the linked article, or the osnews news item, linked to the actual slashdot posting. Either it’s hard to find or it’s not there at all; either way, I’m off to search Slashdot.
Here is the link to Matthew Dillons post.
http://hardware.slashdot.org/comments.pl?sid=242663&cid=19678123
Lets not forget that we are here judging what seems important and logical and not who said it. Knowledge should be more important than fame. Also, the history is full of examples of genius mistakes.
The post of Brendan looks very logical and valid to me as also the context Kaiwai cited.
after all, the ones who do the programming, thus the ones having ‘problems’ with the bugs are them, not us. They should know the best what troubles them. Although we may look at the bugs as an unimportant bugs (i.e. negligible), it might not be the case for them, the ones who face the bugs.
I dont understand.
How is the physical microprocessor buggy? Was a few microscopic curuits wired wrong?
Or is there a driver a CPU needs to function and it is whats buggy?
In a sense it is the circuits wired incorrectly, but not really at that level. The way CPUs are designed is that there’s a model of their logic built in something called RTL (Register Transfer Language) which describes the logical operations that they are meant to perform. Taking X86 instructions and translating them into results is no simple task and modern processors are really hardware JIT compilers between x86 machine code and internal RISC operations. It’s possible to have incorrect edge cases and mistakes in this system.
And yes, Theo and Matt are excellent programmers, but are they really so practical? All issues they have described can be worked around without excessively heroic measures, so these issues are not dealbreakers.
Just a follow up to my last post, something I found on zdnet ( http://blogs.zdnet.com/Ou/?p=559 )
So, one could actually argue that those operating systems affected by the TLB bug are those who chose to use undocumented parts of the processor.
Microsoft have released an update for that:
http://support.microsoft.com/?kbid=936357
Aparently Linux (and I think most *NIX’s) aren’t affected by this issue.
I am just Joe Average and I dunno about these things…..please tell me can and will these be fixed in Penryn?
That is something best directed to Intel.
Does anyone have any information about how other manufacturers are doing on security? These defects appear very serious but I have no context for comparison. Is there a site for tracking this stuff without having to drill through each manufacturer’s list of (disclosed) bugs and errata? How is the Xeon doing? How about the various models from AMD?
Edited 2007-07-02 16:00
Is there any proof of code?