Searching \ for '(OT FWD) Another Pentium BUG ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=another+pentium
Search entire site for: '(OT FWD) Another Pentium BUG ?'.

Truncated match.
PICList Thread
'(OT FWD) Another Pentium BUG ?'
1997\11\10@192640 by Ricardo Seixas

flavicon
face
       I've received this message from a Linux list, since I don't own a Pentiu
m
I'm unable to test this.
       Forgive me to put this OT on the list, my intention is not to start anot
her
endless OT tread.

Ricardo Seixas.

----------------------------------------------------------------------------
-------

{Quote hidden}

CPU.
>As the poster said, no special permissions are needed, the pentium runs under
>ring 3 permissions!!!!

>This means that no secure system can ever be built that uses the pentium
CPU. No
{Quote hidden}

1997\11\11@112814 by ERIC SCHLAEPFER

flavicon
face
Hi,

What the program does is call some sort of assembly program contained in the x
array. I tried running it on my 486 at work and Windows NT caught the fault. I
have het to try it at home on my Pentium. (By the way, my Pentium at home has
that infamous mul/div math bug. There is a program to test for this on the
Gernsback Web site.)

Also, I took the instructions in the array and made them into a .COM executable,
which is what NT caught on my 486.

Here is what my disassembler produced:

0BBA:0100 F0            LOCK
0BBA:0101 0F            DB      0F
0BBA:0102 C7C8xxxx      MOV     AX,2090

The xxxx is replaced by what happens to be in memory at the time of execution.

The LOCK instruction seems to trigger Windows NT.

As for the C program itself, it is considered a bad programming practice to
insert an assembly program like that. Usually people use the Asm block on the
Microsoft and Borland compilers, or the assembly pragma using the Watcom
compiler.

Later,

Eric

______________________________ Reply Separator _________________________________
Subject: (OT FWD) Another Pentium BUG ?
Author:  Ricardo Seixas <spam_OUTrseixasTakeThisOuTspamciclone.com.br> at INTERNET
Date:    11/10/97 5:10 PM


       I've received this message from a Linux list, since I don't own a
Pentium
I'm unable to test this.
       Forgive me to put this OT on the list, my intention is not to start
another
endless OT tread.

Ricardo Seixas.

----------------------------------------------------------------------------
-------

{Quote hidden}

CPU.
>As the poster said, no special permissions are needed, the pentium runs under
>ring 3 permissions!!!!

>This means that no secure system can ever be built that uses the pentium
CPU. No
{Quote hidden}

1997\11\11@124252 by Martin Darwin

flavicon
face
Here is a 1 line C program that will trigger the bug (from comp.sys.intel)
The bug will only occur on pure pentium systems (no 486, Cyrix, PPro or
pentium MMX will show the bug). Also the bug will occure no matter what OS
is running since no special permissions are required to execute the
instruction.

>long main=0xc8c70ff0;
>
>instead
>
>oddly, this compiles fine using
>
>gcc -Wall -pedantic -ansi flaming-death.c -o flaming-death

MD


On Tue, 11 Nov 1997, ERIC SCHLAEPFER wrote:

> Hi,
>
> What the program does is call some sort of assembly program contained in the x
> array. I tried running it on my 486 at work and Windows NT caught the fault. I
> have het to try it at home on my Pentium. (By the way, my Pentium at home has
> that infamous mul/div math bug. There is a program to test for this on the
> Gernsback Web site.)
>
> Also, I took the instructions in the array and made them into a .COM
executable,
{Quote hidden}

_________________________________
{Quote hidden}

1997\11\11@140203 by sajjad.akhtar

flavicon
face
Go and check what instruction has the Hex: f00fc7c8 it might be halt instruction
or any wait. Try to run it on the NT system.

______________________________ Reply Separator _________________________________
Subject: (OT FWD) Another Pentium BUG ?
Author:  pic microcontroller discussion list <PICLISTspamKILLspamMITVMA.MIT.EDU> at smtpgwy
Date:    11/11/97 6:18 AM


       I've received this message from a Linux list, since I don't own a
Pentium
I'm unable to test this.
       Forgive me to put this OT on the list, my intention is not to start
another
endless OT tread.

Ricardo Seixas.

----------------------------------------------------------------------------
-------

{Quote hidden}

CPU.
>As the poster said, no special permissions are needed, the pentium runs under
>ring 3 permissions!!!!

>This means that no secure system can ever be built that uses the pentium
CPU. No
{Quote hidden}

1997\11\11@152448 by John Payson

picon face
> Go and check what instruction has the Hex: f00fc7c8 it might be halt
instruction
> or any wait. Try to run it on the NT system.

The 0xF0 is a "lock" prefix.  This instructs the CPU that the next instruction
should be executed atomically; the prefix is only supposed to be used with
certain instructions.  I don't know what the 0FC7C8 instruction is (the 0F is
a 386-specific prefix byte and I don't have the table handy) but it's probably
an instruction which is not allowed to be "LOCK"'ed.

I think the problem is probably that the "lock" prefix is causing one of
the CPU's execution units to lock the bus and never release it.  On a 486
this situation would simply result in an invalid-instruction trap, but on
the Pentium it apparently does not (or it might be that the instruction DOES
cause an invalid-instruction trap, but with the bus locked; the interrupt
logic might then be stuck forever waiting to stack the program state.

Still, it is disturbing that no Pentium OS can be written to be immune to
denial-of-service attacks.

1997\11\11@194228 by Anil K. Patel

flavicon
face
On Tuesday, November 11, 1997 12:11 PM, John Payson [SMTP:.....supercatKILLspamspam.....MCS.NET]
wrote:
> > Go and check what instruction has the Hex: f00fc7c8 it might be halt
>  instruction
> > or any wait. Try to run it on the NT system.
>
> The 0xF0 is a "lock" prefix.  This instructs the CPU that the next
instruction
> should be executed atomically; the prefix is only supposed to be used
with
> certain instructions.  I don't know what the 0FC7C8 instruction is (the
0F is
> a 386-specific prefix byte and I don't have the table handy) but it's
probably
> an instruction which is not allowed to be "LOCK"'ed.
>
> I think the problem is probably that the "lock" prefix is causing one of
> the CPU's execution units to lock the bus and never release it.  On a 486
> this situation would simply result in an invalid-instruction trap, but on
> the Pentium it apparently does not (or it might be that the instruction
DOES
> cause an invalid-instruction trap, but with the bus locked; the interrupt
> logic might then be stuck forever waiting to stack the program state.
>
> Still, it is disturbing that no Pentium OS can be written to be immune to
> denial-of-service attacks.
>

I looked up the code sequence and 0xf0 is the LOCK prefix.  The 0x0f is a
two-byte instruction escape, so it combines with 0xc7.  The 0x0f 0xc7
combination is invalid according to the Pentium and 486 programming
reference manuals.  But who knows, maybe its a undocumented instruction.

The sequence should generate an invalid opcode fault, which the OS should
trap.

--Anil

1997\11\12@074744 by Paul BRITTON

flavicon
face
>>>
>>> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>>>
>>> main ()
>>> {
>>>        void (*f)() = x;
>>>        f();
>>> }
>>>

We have compiled and run this on Borland C++ V5.0 on a Compaq Prolinear 590
running Win95a and it traps the error correctly

1997\11\12@103351 by Andy Kunz

flavicon
face
At 12:34 PM 11/12/97 +0000, you wrote:
>>>>
>>>> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>>>>
>>>> main ()
>>>> {
>>>>        void (*f)() = x;
>>>>        f();
>>>> }
>>>>
>
>We have compiled and run this on Borland C++ V5.0 on a Compaq Prolinear 590
> running Win95a and it traps the error correctly

Kinda like self-modifying code.  Neat trick.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\11\12@110630 by David Gould

flavicon
face
>
> At 12:34 PM 11/12/97 +0000, you wrote:
> >>>>
> >>>> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
> >>>>
> >>>> main ()
> >>>> {
> >>>>        void (*f)() = x;
> >>>>        f();
> >>>> }
> >>>>
> >
> >We have compiled and run this on Borland C++ V5.0 on a Compaq Prolinear 590
> > running Win95a and it traps the error correctly
>
> Kinda like self-modifying code.  Neat trick.
>

The really neat trick on this topic is:

long main = 0xc8c70ff0;

-dg

David Gould            EraseMEdgspam_OUTspamTakeThisOuTillustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
- I realize now that irony has no place in business communications.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...