Linked by Thom Holwerda on Sat 30th Jun 2007 17:19 UTC, submitted by doro
Intel "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."
Thread beginning with comment 252013
To read all comments associated with this story, please click here.
Some inaccuracies..
by Brendan on Sat 30th Jun 2007 18:42 UTC
Brendan
Member since:
2005-11-16

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

Reply Score: 5

RE: Some inaccuracies..
by Oliver on Sat 30th Jun 2007 19:17 in reply to "Some inaccuracies.."
Oliver Member since:
2006-07-15

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

Reply Parent Score: 5

RE[2]: Some inaccuracies..
by jelway on Sun 1st Jul 2007 00:19 in reply to "RE: Some inaccuracies.."
jelway Member since:
2006-05-14

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.

Reply Parent Score: 3

RE[2]: Some inaccuracies..
by kaiwai on Sun 1st Jul 2007 00:22 in reply to "RE: Some inaccuracies.."
kaiwai Member since:
2005-07-06

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


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.

Reply Parent Score: 5

RE[2]: Some inaccuracies..
by butters on Sun 1st Jul 2007 05:57 in reply to "RE: Some inaccuracies.."
butters Member since:
2005-07-08

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.

Reply Parent Score: 5

RE: Some inaccuracies..
by Janizary on Sat 30th Jun 2007 21:09 in reply to "Some inaccuracies.."
Janizary Member since:
2006-03-12

Right, because we should trust you, some nobody from nowhere that's done nothing, over two of the world's biggest hackers.

Reply Parent Score: 1

RE[2]: Some inaccuracies..
by Lazarus on Sun 1st Jul 2007 00:02 in reply to "RE: Some inaccuracies.."
Lazarus Member since:
2005-08-10

"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

Reply Parent Score: 4

RE[2]: Some inaccuracies..
by jelway on Sun 1st Jul 2007 00:20 in reply to "RE: Some inaccuracies.."
jelway Member since:
2006-05-14

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.

Reply Parent Score: 4

RE[2]: Some inaccuracies..
by Brendan on Sun 1st Jul 2007 00:55 in reply to "RE: Some inaccuracies.."
Brendan Member since:
2005-11-16

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

Reply Parent Score: 5

RE[2]: Some inaccuracies..
by StephenBeDoper on Sun 1st Jul 2007 04:57 in reply to "RE: Some inaccuracies.."
StephenBeDoper Member since:
2005-07-06

When you say "biggest," do you mean in terms of height, width, or girth?

Reply Parent Score: 3

RE[2]: Some inaccuracies..
by NxStY on Sun 1st Jul 2007 09:49 in reply to "RE: Some inaccuracies.."
NxStY Member since:
2005-11-12

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.

Reply Parent Score: 3

RE[2]: Some inaccuracies..
by Cloudy on Tue 3rd Jul 2007 02:39 in reply to "RE: Some inaccuracies.."
Cloudy Member since:
2006-02-15

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

Reply Parent Score: 2

RE: Some inaccuracies..
by happycamper on Mon 2nd Jul 2007 11:50 in reply to "Some inaccuracies.."
happycamper Member since:
2006-01-01

alot of those bugs I think are consider show stopper bugs.

Reply Parent Score: 1