OSNews

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.

>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=...

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.

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

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.

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/

Here is the link to Matthew Dillons post.
http://hardware.slashdot.org/comments.pl?sid=242663&cid=1967812...

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.

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.

That is something best directed to Intel.