Intel Corporation (INTC) Message Board

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Intel Corporation (INTC)

INTC 36.15

-0.6%

Dec 24 12:59 PM EST

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next

To: Gary Kao who wrote (39489)	11/9/1997 7:00:00 PM
From: Jeroen Pluimers	Read Replies (2) of 186894

Gary, This bug is NOT garbage. I have done some digging on the relevant usenet posts and some checking myself. A summary is below. The Pentium F0 bug consists of a four byte sequence with these values detected to show buggy behaviour. These sequences are F0 0F C7 C8 trough F0 0F C7 CF (all values in hexadecimal). The affected instruction is basically meaningless and decodes to a LOCK CMPXCHG8B instruction that does refers to the EAX trough EDI registers. Since the instruction is not valid, an invalid instruction opcode exception should be generated by the processor. Most proccessors handle this correctly, however some don't. The only ones showing buggy behaviour are these: P54C series (the 'classic' Pentium) P55C series (the 'new' Pentium MMX) These series include the mobile versions of these processors. It seems that all other processors are unaffected including Intel Pentium Pro, Intel Pentium II, AMD and Cyrix Pentium compatible processors. The problem is severe because the faulty processors do not generate an invalid instruction opcode exception, but completely lockup. Since it does not matter at which privilige level the instruction is executed, any process in the system can now completely lockup a system completely. Some kinds of systems that are in great potential danger include, but are not limited to: - Time sharing systems that run processes from multiple users (for instance the machines your ISP uses to let you logon an interactive session and run your own software) - Web-servers that allow their users to run user-defines CGI programs - End-users that allow their systems to run malicious ActiveX applications that have not been screened well enough - Systems infected by a virus incorporating this bug-revealing code Of course only systems are affected where someone is willingly trying to run malicious code. However, the chance of protecting a system against this code depends on how open the system must be in order to function at all. To prevent damage, the following actions should be taken until Intel has found better countremeasures: - Time sharing systems should limit their entrance to trusted users - Web-servers should deny non-screened CGI scripts and limit those scripts to trusted users - End-users should either disable ActiveX at all or only run ActiveX components using the highest screening level possible - Everyone should run virus checking software at all times In addition, all systems should keep log-files tracking (and saving to disk) execution of any piece of software before it gets executed. This facilitates tracing back what piece of software brought down the system. jeroen

Report TOU Violation

Share This Post

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next