Any illegal instruction processing interrupts? 
Author Message
 Any illegal instruction processing interrupts?

Is there an interrupt on the Intel CPU's that gets fired upon trying to
execute an illegal instruction?  I've read quite a bit on the M68k
series and they actually had that.


Mon, 11 Jul 2005 07:55:04 GMT  
 Any illegal instruction processing interrupts?
| Is there an interrupt on the Intel CPU's that gets fired upon trying
| to execute an illegal instruction?  I've read quite a bit on the M68k
| series and they actually had that.

Yes, interrupt 6.

--
Tim Robinson, MVP (Windows SDK)
http://www.themobius.co.uk/



Mon, 11 Jul 2005 08:06:49 GMT  
 Any illegal instruction processing interrupts?

Quote:

>Is there an interrupt on the Intel CPU's that gets fired upon trying to
>execute an illegal instruction?  I've read quite a bit on the M68k
>series and they actually had that.

This has been present at least since the 80286, if you dissassemble
the BIOS #UD handler it is sometimes interesting, at least I've seen
BIOS code that tries to support undocumented things like LOADALL...

From 286INTEL.TXT, 80286 documentation;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#UD 6 Undefined Opcode (No Error Code)

This exception is generated when an invalid operation code is detected in
the instruction stream. Following are the cases in which #UD can occur:

  1.  The first byte of an instruction is completely invalid (e.g., 64H).

  2.  The first byte indicates a 2-byte opcode and the second byte is
      invalid (e.g., 0FH followed by 0FFH).

  3.  An invalid register is used with an otherwise valid opcode (e.g., MOV
      CS,AX).

  4.  An invalid opcode extension is given in the REG field of the ModRM
      byte (e.g., 0F6H /1).

  5.  A register operand is given in an instruction that requires a memory
      operand (e.g., LGDT AX).

Since the offending opcode will always be invalid, it cannot be restarted.
However, the #UD handler might be coded to implement an extension of the
80286 instruction set. In that case, the handler could advance the return
pointer beyond the extended instruction and return control to the program
after the extended instruction is emulated. Any such extensions may be
incompatible with the 80386.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

bestwishes
laura



Wed, 13 Jul 2005 11:25:49 GMT  
 Any illegal instruction processing interrupts?

Well, with the M68K, Apple decided to get slick with MacOS and actually
make it so that the way you call their system calls is by putting an
illegal opcode in your program.  What would happen is that then the
illegal instruction handler would kick in and actually consult an API
table of pointers to system calls, using the illegal opcode itself as an
index.  What's the problem with this?  Guess what, Motorola couldn't
exactly use that feature for instruction set expansion anymore!  BTW,
Palm OS uses a similar mechanism.

It'd be interesting if Intel ever would suffer the same fate with their
implementation....

Quote:


>>Is there an interrupt on the Intel CPU's that gets fired upon trying to
>>execute an illegal instruction?  I've read quite a bit on the M68k
>>series and they actually had that.

>This has been present at least since the 80286, if you dissassemble
>the BIOS #UD handler it is sometimes interesting, at least I've seen
>BIOS code that tries to support undocumented things like LOADALL...

>From 286INTEL.TXT, 80286 documentation;

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>#UD 6 Undefined Opcode (No Error Code)

>This exception is generated when an invalid operation code is detected in
>the instruction stream. Following are the cases in which #UD can occur:

>  1.  The first byte of an instruction is completely invalid (e.g., 64H).

>  2.  The first byte indicates a 2-byte opcode and the second byte is
>      invalid (e.g., 0FH followed by 0FFH).

>  3.  An invalid register is used with an otherwise valid opcode (e.g., MOV
>      CS,AX).

>  4.  An invalid opcode extension is given in the REG field of the ModRM
>      byte (e.g., 0F6H /1).

>  5.  A register operand is given in an instruction that requires a memory
>      operand (e.g., LGDT AX).

>Since the offending opcode will always be invalid, it cannot be restarted.
>However, the #UD handler might be coded to implement an extension of the
>80286 instruction set. In that case, the handler could advance the return
>pointer beyond the extended instruction and return control to the program
>after the extended instruction is emulated. Any such extensions may be
>incompatible with the 80386.

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>bestwishes
>laura



Thu, 14 Jul 2005 08:01:48 GMT  
 Any illegal instruction processing interrupts?

Quote:

>--------------080502030501080803010809
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit

>Well, with the M68K, Apple decided to get slick with MacOS and actually
>make it so that the way you call their system calls is by putting an
>illegal opcode in your program.  What would happen is that then the
>illegal instruction handler would kick in and actually consult an API
>table of pointers to system calls, using the illegal opcode itself as an
>index.  What's the problem with this?  Guess what, Motorola couldn't
>exactly use that feature for instruction set expansion anymore!  BTW,
>Palm OS uses a similar mechanism.

>It'd be interesting if Intel ever would suffer the same fate with their
>implementation....

I haven't heard of anything that uses invalid op-codes to call the
operating system, and as you say it's an extremely bad design decision
really because (of course) if a code is invalid in the current generation
CPU that doesn't mean to say they won't use it in the next. OTOH, if
the software producers are really big they might just be able to tell
the CPU manufacturers what to do... it's well known that for some years
Intel have built features into the x86 line on-demand from Microsoft.

It appears to me that something in the converse sense happened
with the undocumented LOADALL instruction, there was a 286 LOADALL
instruction (0F 05) and then when the 386 came about Intel added
a new incompatible 386 LOADALL (0F 07)(*) and got rid of the original
one. They issued documentation to BIOS developers which included
code on how to emulate the 286 LOADALL command on a 386, and you
can see that code if you disassemble some BIOSes INT 06. So, this
I suppose is how the interrupt *should* be used, ;-) Also it's used
to do things like emulate an FPU when the FPU isn't there..

(*) I should suppose modern codes are more difficult to find than
exhaustively scanning through the op-codes; there are so many ways
to hide things with MSRs and Intel don't document them for a good
reason.

byefornow
laura

- Show quoted text -

Quote:



>>>Is there an interrupt on the Intel CPU's that gets fired upon trying to
>>>execute an illegal instruction?  I've read quite a bit on the M68k
>>>series and they actually had that.

>>This has been present at least since the 80286, if you dissassemble
>>the BIOS #UD handler it is sometimes interesting, at least I've seen
>>BIOS code that tries to support undocumented things like LOADALL...

>>From 286INTEL.TXT, 80286 documentation;

>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>>#UD 6 Undefined Opcode (No Error Code)

>>This exception is generated when an invalid operation code is detected in
>>the instruction stream. Following are the cases in which #UD can occur:

>>  1.  The first byte of an instruction is completely invalid (e.g., 64H).

>>  2.  The first byte indicates a 2-byte opcode and the second byte is
>>      invalid (e.g., 0FH followed by 0FFH).

>>  3.  An invalid register is used with an otherwise valid opcode (e.g., MOV
>>      CS,AX).

>>  4.  An invalid opcode extension is given in the REG field of the ModRM
>>      byte (e.g., 0F6H /1).

>>  5.  A register operand is given in an instruction that requires a memory
>>      operand (e.g., LGDT AX).

>>Since the offending opcode will always be invalid, it cannot be restarted.
>>However, the #UD handler might be coded to implement an extension of the
>>80286 instruction set. In that case, the handler could advance the return
>>pointer beyond the extended instruction and return control to the program
>>after the extended instruction is emulated. Any such extensions may be
>>incompatible with the 80386.

>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>>bestwishes
>>laura

>--------------080502030501080803010809
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit

><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
><html>

--
alt.fan.madonna |news, interviews, discussion, writings
                |chat, exchange merchandise, meet fans....
                |Get into the groove baby you've got to... check us out!


Thu, 14 Jul 2005 12:04:49 GMT  
 Any illegal instruction processing interrupts?

What's an MSR?

And what instructions have been built in on M$ request?  I didn't know
about this, but I always suspected stuff like this.

Quote:


>>--------------080502030501080803010809
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>Content-Transfer-Encoding: 7bit

>>Well, with the M68K, Apple decided to get slick with MacOS and actually
>>make it so that the way you call their system calls is by putting an
>>illegal opcode in your program.  What would happen is that then the
>>illegal instruction handler would kick in and actually consult an API
>>table of pointers to system calls, using the illegal opcode itself as an
>>index.  What's the problem with this?  Guess what, Motorola couldn't
>>exactly use that feature for instruction set expansion anymore!  BTW,
>>Palm OS uses a similar mechanism.

>>It'd be interesting if Intel ever would suffer the same fate with their
>>implementation....

>I haven't heard of anything that uses invalid op-codes to call the
>operating system, and as you say it's an extremely bad design decision
>really because (of course) if a code is invalid in the current generation
>CPU that doesn't mean to say they won't use it in the next. OTOH, if
>the software producers are really big they might just be able to tell
>the CPU manufacturers what to do... it's well known that for some years
>Intel have built features into the x86 line on-demand from Microsoft.

>It appears to me that something in the converse sense happened
>with the undocumented LOADALL instruction, there was a 286 LOADALL
>instruction (0F 05) and then when the 386 came about Intel added
>a new incompatible 386 LOADALL (0F 07)(*) and got rid of the original
>one. They issued documentation to BIOS developers which included
>code on how to emulate the 286 LOADALL command on a 386, and you
>can see that code if you disassemble some BIOSes INT 06. So, this
>I suppose is how the interrupt *should* be used, ;-) Also it's used
>to do things like emulate an FPU when the FPU isn't there..

>(*) I should suppose modern codes are more difficult to find than
>exhaustively scanning through the op-codes; there are so many ways
>to hide things with MSRs and Intel don't document them for a good
>reason.

>byefornow
>laura



>>>>Is there an interrupt on the Intel CPU's that gets fired upon trying to
>>>>execute an illegal instruction?  I've read quite a bit on the M68k
>>>>series and they actually had that.

>>>This has been present at least since the 80286, if you dissassemble
>>>the BIOS #UD handler it is sometimes interesting, at least I've seen
>>>BIOS code that tries to support undocumented things like LOADALL...

>>>From 286INTEL.TXT, 80286 documentation;

>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>>>#UD 6 Undefined Opcode (No Error Code)

>>>This exception is generated when an invalid operation code is detected in
>>>the instruction stream. Following are the cases in which #UD can occur:

>>> 1.  The first byte of an instruction is completely invalid (e.g., 64H).

>>> 2.  The first byte indicates a 2-byte opcode and the second byte is
>>>     invalid (e.g., 0FH followed by 0FFH).

>>> 3.  An invalid register is used with an otherwise valid opcode (e.g., MOV
>>>     CS,AX).

>>> 4.  An invalid opcode extension is given in the REG field of the ModRM
>>>     byte (e.g., 0F6H /1).

>>> 5.  A register operand is given in an instruction that requires a memory
>>>     operand (e.g., LGDT AX).

>>>Since the offending opcode will always be invalid, it cannot be restarted.
>>>However, the #UD handler might be coded to implement an extension of the
>>>80286 instruction set. In that case, the handler could advance the return
>>>pointer beyond the extended instruction and return control to the program
>>>after the extended instruction is emulated. Any such extensions may be
>>>incompatible with the 80386.

>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>>>bestwishes
>>>laura

>>--------------080502030501080803010809
>>Content-Type: text/html; charset=us-ascii
>>Content-Transfer-Encoding: 7bit

>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>><html>



Thu, 14 Jul 2005 13:39:38 GMT  
 Any illegal instruction processing interrupts?
I'm surprised no one has pointed this out and how few people seem to
know about it:

http://www.woodmann.com/fravia/rcgreve1.htm
http://www.flirble.org/chrisy/vmm386/tech-man/vmm-tech_6.html#SEC84

This "ARPL" feature of Win9x makes debugging true invalid opcodes
annoying if they only happened when running something in a DOS box

On Sun, 26 Jan 2003 04:04:49 +0000 (UTC),

Quote:


>>--------------080502030501080803010809
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>Content-Transfer-Encoding: 7bit

>>Well, with the M68K, Apple decided to get slick with MacOS and actually
>>make it so that the way you call their system calls is by putting an
>>illegal opcode in your program.  What would happen is that then the
>>illegal instruction handler would kick in and actually consult an API
>>table of pointers to system calls, using the illegal opcode itself as an
>>index.  What's the problem with this?  Guess what, Motorola couldn't
>>exactly use that feature for instruction set expansion anymore!  BTW,
>>Palm OS uses a similar mechanism.

>>It'd be interesting if Intel ever would suffer the same fate with their
>>implementation....

>I haven't heard of anything that uses invalid op-codes to call the
>operating system, and as you say it's an extremely bad design decision
>really because (of course) if a code is invalid in the current generation
>CPU that doesn't mean to say they won't use it in the next. OTOH, if
>the software producers are really big they might just be able to tell
>the CPU manufacturers what to do... it's well known that for some years
>Intel have built features into the x86 line on-demand from Microsoft.

>It appears to me that something in the converse sense happened
>with the undocumented LOADALL instruction, there was a 286 LOADALL
>instruction (0F 05) and then when the 386 came about Intel added
>a new incompatible 386 LOADALL (0F 07)(*) and got rid of the original
>one. They issued documentation to BIOS developers which included
>code on how to emulate the 286 LOADALL command on a 386, and you
>can see that code if you disassemble some BIOSes INT 06. So, this
>I suppose is how the interrupt *should* be used, ;-) Also it's used
>to do things like emulate an FPU when the FPU isn't there..

>(*) I should suppose modern codes are more difficult to find than
>exhaustively scanning through the op-codes; there are so many ways
>to hide things with MSRs and Intel don't document them for a good
>reason.

>byefornow
>laura



Fri, 15 Jul 2005 01:12:45 GMT  
 Any illegal instruction processing interrupts?

Quote:


> >--------------080502030501080803010809
> >Content-Type: text/plain; charset=us-ascii; format=flowed
> >Content-Transfer-Encoding: 7bit

> >Well, with the M68K, Apple decided to get slick with MacOS and actually
> >make it so that the way you call their system calls is by putting an
> >illegal opcode in your program.  What would happen is that then the
> >illegal instruction handler would kick in and actually consult an API
> >table of pointers to system calls, using the illegal opcode itself as an
> >index.  What's the problem with this?  Guess what, Motorola couldn't
> >exactly use that feature for instruction set expansion anymore!  BTW,
> >Palm OS uses a similar mechanism.

> >It'd be interesting if Intel ever would suffer the same fate with their
> >implementation....

> I haven't heard of anything that uses invalid op-codes to call the
> operating system,

1) All Windows family uses special form of invalid opcode to call VxDs
from user (CPL-3) mode.
2) All Windows NT family uses special form of invalid opcode to call
virtual device drivers from V86-mode support drivers.
3) I used a special form of invalid opcode for a kind of
anti-debugging API (protect CPL-3 programs from kernel-mode de{*filter*}s)
under all Windows 3.1+, Windows NT+ and OS/2 2.0+ families.

Quote:
> and as you say it's an extremely bad design decision
> really because (of course) if a code is invalid in the current generation
> CPU that doesn't mean to say they won't use it in the next.

   Nope, certain forms of invalid opcodes will never be valid. In the
first place, invalid combinations of R/M operands for memory-only
instructions, like LEA, LDS/ES/SS/FS/GS, indirect CALL FAR / JMP FAR
and LOCK-prefixed instructions. Some other instructions (like ARPL)
are protected-mode only and will always be invalid in V86 mode.
Others, like LOADALL and/or MOV to/from TRs have been officially
un-defined.

   Normally assemblers won't accept "CALL FAR EAX"-like instructions,
too, so you'll have to construct them by hand, but with the opcode
table it's fairly easy.

/BP



Mon, 18 Jul 2005 03:16:45 GMT  
 Any illegal instruction processing interrupts?

Sounds like you could get a job as an OS developer... Your knowledge is
quite impressive :-)

Quote:



>>>--------------080502030501080803010809
>>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>>Content-Transfer-Encoding: 7bit

>>>Well, with the M68K, Apple decided to get slick with MacOS and actually
>>>make it so that the way you call their system calls is by putting an
>>>illegal opcode in your program.  What would happen is that then the
>>>illegal instruction handler would kick in and actually consult an API
>>>table of pointers to system calls, using the illegal opcode itself as an
>>>index.  What's the problem with this?  Guess what, Motorola couldn't
>>>exactly use that feature for instruction set expansion anymore!  BTW,
>>>Palm OS uses a similar mechanism.

>>>It'd be interesting if Intel ever would suffer the same fate with their
>>>implementation....

>>I haven't heard of anything that uses invalid op-codes to call the
>>operating system,

>1) All Windows family uses special form of invalid opcode to call VxDs
>from user (CPL-3) mode.
>2) All Windows NT family uses special form of invalid opcode to call
>virtual device drivers from V86-mode support drivers.
>3) I used a special form of invalid opcode for a kind of
>anti-debugging API (protect CPL-3 programs from kernel-mode de{*filter*}s)
>under all Windows 3.1+, Windows NT+ and OS/2 2.0+ families.

>>and as you say it's an extremely bad design decision
>>really because (of course) if a code is invalid in the current generation
>>CPU that doesn't mean to say they won't use it in the next.

>   Nope, certain forms of invalid opcodes will never be valid. In the
>first place, invalid combinations of R/M operands for memory-only
>instructions, like LEA, LDS/ES/SS/FS/GS, indirect CALL FAR / JMP FAR
>and LOCK-prefixed instructions. Some other instructions (like ARPL)
>are protected-mode only and will always be invalid in V86 mode.
>Others, like LOADALL and/or MOV to/from TRs have been officially
>un-defined.

>   Normally assemblers won't accept "CALL FAR EAX"-like instructions,
>too, so you'll have to construct them by hand, but with the opcode
>table it's fairly easy.

>/BP



Mon, 18 Jul 2005 10:55:07 GMT  
 Any illegal instruction processing interrupts?

Quote:

> Sounds like you could get a job as an OS developer... Your knowledge is
> quite impressive :-)

   Guess that's what I've been doing for a job in the last decade -
mucking with various OS kernels, Windows 3.x/9x, NT, OS/2, pSOS+, UNIX
(commercial & Linux), drivers, syscall modules and such stuff... Right
now it's Linux :-) Even my graduate project was an embedded OS.

/BP



Mon, 18 Jul 2005 20:00:18 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Illegal Instruction Workaround

2. clipper & nt illegal instruction

3. Windows NT 3.5 Illegal Instruction

4. Illegal instructions

5. Why does this give illegal instruction?

6. Illegal instruction (core dumped)

7. drand : illegal instruction ???

8. Illegal Instruction on Mac OS X Intel

9. Illegal Instruction in Tcl_Eval()

10. 'after' causes illegal instruction errors

11. DOS interrupts & asm instructions

12. Bizarre results of IRET instruction while returning from IDLE interrupt handler

 

 
Powered by phpBB® Forum Software