> On Fri, 7 Nov 1997, Robert R. Collins wrote:
>
> > Richard B. Johnson, you wrote:
> > >
> > >The following user-mode program will stop the internal clock
> > >of a Pentium.
> >
> > Actually, it doesn't stop the internal clock. It sends out two
> > (back-to-back) locked memory read cycles, without any intervening locked
> > memory write cycles. This (most likely) causes the state machines of the
> > chipsets to go bonkers. The net effect is a crashed system.
> >
> > >
> > >char x[5]={0xf0,0x0f,0xc7,0xc8,0x00};
Is is possible to make a kernel patch or something else to keep an
eye out for these byte codes? Without some sort of protection this could
case some major problems with pentium based linux boxes.
Cheers Adam
>
> Well, according to my bus analyzer and an educated finger, the chip
> stops __cold__ literly. The external chip temperature goes to
> ambient from a nominal 22-28 degC above ambient and the power supply
> load current goes way down.
>
> All of these code-sequences cause the same effect.
>
> 0xf0,0x0f,0xc7,0xc8
> 0xf0,0x0f,0xc7,0xc9
> 0xf0,0x0f,0xc7,0xca
> 0xf0,0x0f,0xc7,0xcb
> 0xf0,0x0f,0xc7,0xcc
> 0xf0,0x0f,0xc7,0xcd
> 0xf0,0x0f,0xc7,0xce
> 0xf0,0x0f,0xc7,0xcf
>
> I made a simple program to perform an exhaustive search of bad
> opcodes that can crash a protected-mode system from user-mode.
>
>
> Cheers,
> Dick Johnson
>
> Richard B. Johnson
> Project Engineer
> Analogic Corporation
> Penguin : Linux version 2.1.60 on an i586 machine (66.15 BogoMips).
> Warning : It's hard to remain at the trailing edge of technology.
>