On Tuesday, November 11, 1997 12:11 PM, John Payson [SMTP:supercat@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