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."
Order by: Score:
Every arch has its bugs
by RafaelRR on Sat 30th Jun 2007 18:42 UTC
RafaelRR
Member since:
2006-06-20

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

Reply Score: 2

RE: Every arch has its bugs
by Kroc on Sat 30th Jun 2007 22:12 UTC in reply to "Every arch has its bugs"
Kroc Member since:
2005-11-10

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.

Reply Score: 5

RE[2]: Every arch has its bugs
by flanque on Sat 30th Jun 2007 23:11 UTC in reply to "RE: Every arch has its bugs"
flanque Member since:
2005-12-15

Awww.. stop it! You're bring back ssoo many fond memories.. 6502.. beautiful piece of hardware for its time.

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.


Accident, or perhaps secretly shared knowledge not meant for the masses?

Edited 2007-06-30 23:12

Reply Score: 2

RE: Every arch has its bugs
by Headrush on Sat 30th Jun 2007 23:07 UTC in reply to "Every arch has its bugs"
Headrush Member since:
2006-01-03

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.

Reply Score: 5

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 UTC 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 Score: 5

RE[2]: Some inaccuracies..
by jelway on Sun 1st Jul 2007 00:19 UTC 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 Score: 3

RE[2]: Some inaccuracies..
by kaiwai on Sun 1st Jul 2007 00:22 UTC 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 Score: 5

RE[2]: Some inaccuracies..
by butters on Sun 1st Jul 2007 05:57 UTC 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 Score: 5

RE[3]: Some inaccuracies..
by pepa on Mon 2nd Jul 2007 05:50 UTC in reply to "RE[2]: Some inaccuracies.."
pepa Member since:
2005-07-08

[OT] What has been happening in your life, butters? I used to think everyone of your posts was sublime, until around this month..!

Reply Score: 0

RE: Some inaccuracies..
by Janizary on Sat 30th Jun 2007 21:09 UTC 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 Score: 1

RE[2]: Some inaccuracies..
by Lazarus on Sun 1st Jul 2007 00:02 UTC 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 Score: 4

RE[3]: Some inaccuracies..
by Janizary on Sun 1st Jul 2007 00:17 UTC in reply to "RE[2]: Some inaccuracies.."
Janizary Member since:
2006-03-12

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.

Reply Score: 4

RE[2]: Some inaccuracies..
by jelway on Sun 1st Jul 2007 00:20 UTC 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 Score: 4

RE[3]: Some inaccuracies..
by Gone fishing on Sun 1st Jul 2007 05:38 UTC in reply to "RE[2]: Some inaccuracies.."
Gone fishing Member since:
2006-02-22
RE[2]: Some inaccuracies..
by Brendan on Sun 1st Jul 2007 00:55 UTC 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 Score: 5

RE[2]: Some inaccuracies..
by StephenBeDoper on Sun 1st Jul 2007 04:57 UTC 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 Score: 3

RE[3]: Some inaccuracies..
by Janizary on Sun 1st Jul 2007 05:30 UTC in reply to "RE[2]: Some inaccuracies.."
Janizary Member since:
2006-03-12

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.

Reply Score: 2

RE[4]: Some inaccuracies..
by danieldk on Sun 1st Jul 2007 08:39 UTC in reply to "RE[3]: Some inaccuracies.."
danieldk Member since:
2005-11-18

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.

Reply Score: 5

RE[5]: Some inaccuracies..
by Janizary on Sun 1st Jul 2007 19:40 UTC in reply to "RE[4]: Some inaccuracies.."
Janizary Member since:
2006-03-12

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.

Reply Score: 2

RE[6]: Some inaccuracies..
by StephenBeDoper on Mon 2nd Jul 2007 16:02 UTC in reply to "RE[5]: Some inaccuracies.."
StephenBeDoper Member since:
2005-07-06

If someone has a proven track record of making logical, justified statements, they have earned a level of trust and authority in matters


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

while a noone from the shadows does not hold any such prestige.


No, but that doesn't make it intellectually-justified to dismiss an argument solely because of the source.

Reply Score: 2

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

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.

Reply Score: 2

RE[4]: Some inaccuracies..
by javiercero1 on Sun 1st Jul 2007 16:27 UTC in reply to "RE[3]: Some inaccuracies.."
javiercero1 Member since:
2005-11-10

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

Reply Score: 0

RE[2]: Some inaccuracies..
by NxStY on Sun 1st Jul 2007 09:49 UTC 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 Score: 3

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

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.

Reply Score: 2

RE[4]: Some inaccuracies..
by corentin on Tue 3rd Jul 2007 09:58 UTC in reply to "RE[3]: Some inaccuracies.."
corentin Member since:
2005-08-08

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

Reply Score: 2

RE[5]: Some inaccuracies..
by Cloudy on Wed 4th Jul 2007 05:08 UTC in reply to "RE[4]: Some inaccuracies.."
Cloudy Member since:
2006-02-15

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.

Reply Score: 2

RE[2]: Some inaccuracies..
by Cloudy on Tue 3rd Jul 2007 02:39 UTC 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 Score: 2

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

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

Reply Score: 1

The real followup..
by deanna on Sat 30th Jun 2007 19:19 UTC
deanna
Member since:
2006-10-01

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.

Reply Score: 5

RE: The real followup..
by Oliver on Sat 30th Jun 2007 19:31 UTC in reply to "The real followup.."
Oliver Member since:
2006-07-15

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.

Reply Score: 4

RE: The real followup..
by Jimbo on Sun 1st Jul 2007 11:37 UTC in reply to "The real followup.."
Jimbo Member since:
2005-07-22

"intel provides the microcode updates only to MS and hardware vendors."

http://urbanmyth.org/microcode/

Reply Score: 2

Slashdot link?
by Gorgak on Sat 30th Jun 2007 19:35 UTC
Gorgak
Member since:
2007-05-30

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.

Reply Score: 2

RE: Slashdot link?
by jonte on Sat 30th Jun 2007 19:45 UTC in reply to "Slashdot link?"
jonte Member since:
2005-07-06

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

Reply Score: 5

Arguments
by acobar on Sun 1st Jul 2007 03:07 UTC
acobar
Member since:
2005-11-15

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.

Reply Score: 4

RE: Arguments
by edogawaconan on Sun 1st Jul 2007 04:45 UTC in reply to "Arguments"
edogawaconan Member since:
2006-10-10

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.

Reply Score: 1

Huh?
by Xaero_Vincent on Sun 1st Jul 2007 04:35 UTC
Xaero_Vincent
Member since:
2006-08-18

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?

Reply Score: 1

RE: Huh?
by PlatformAgnostic on Sun 1st Jul 2007 06:44 UTC in reply to "Huh?"
PlatformAgnostic Member since:
2006-01-02

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.

Reply Score: 4

Interesting
by kaiwai on Mon 2nd Jul 2007 00:57 UTC
kaiwai
Member since:
2005-07-06

Just a follow up to my last post, something I found on zdnet ( http://blogs.zdnet.com/Ou/?p=559 )

This canít even be considered a bug because software developers were taking advantage of an undocumented behavior of the TLB in prior generations of Intelís Microprocessors. Because this undocumented behavior was changed and now documented in the newer Core 2 processor, it has a very small chance of breaking code that used undocumented behavior though the issue hasnít really been seen in the wild.


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.

Reply Score: 2

Panic or no?
by sumone on Mon 2nd Jul 2007 09:30 UTC
sumone
Member since:
2007-02-11

I am just Joe Average and I dunno about these things.....please tell me can and will these be fixed in Penryn?

Reply Score: 1

RE: Panic or no?
by Lazarus on Mon 2nd Jul 2007 11:47 UTC in reply to "Panic or no?"
Lazarus Member since:
2005-08-10

That is something best directed to Intel.

Reply Score: 2

How does Core 2 compare to others?
by phoehne on Mon 2nd Jul 2007 15:57 UTC
phoehne
Member since:
2006-08-26

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

Reply Score: 1

proof of code
by netpython on Tue 3rd Jul 2007 07:12 UTC
netpython
Member since:
2005-07-06

Is there any proof of code?

Reply Score: 2