7 ms·

I'm not much of an x86 person but on other architectures you can raise software interrupts/exceptions. Does x86 not have this or did those facilities not cover

by Neywiny 21d ago

I'm not much of an x86 person but on other architectures you can raise software interrupts/exceptions. Does x86 not have this or did those facilities not cover enough use cases?

349ru3h4f03 21d ago
x86 has... INT Ib INT1 INT3 INTO BOUND
- userbinator 18d ago
  Note that INT1 was originally called ICEBP before Intel finally documented it publicly (very recently).
  - rep_lodsb 17d ago
    Yes, and it's not quite the same as a normal "INT 01h". It causes a debug exception, which may enter ICE mode if it is enabled (undocumented bit in DR7, or PMCR on Pentium), otherwise it invokes interrupt 1, but without checking the privilege level on the IDT entry, or the interrupt redirection bitmap in V86 mode. https://www.rcollins.org/secrets/opcodes/ICEBP.html https://www.rcollins.org/secrets/opcodes/ICEBP.html IIRC, older versions of the Linux kernel had a security bug because they didn't expect this to happen. ICE mode was sort of a precursor to SMM, but both also coexisted for a time with slightly different behaviour. It was introduced in the 286, where instead of ICEBP there was "STOREALL" (opcode 0F04). F1 on that processor was a prefix instead, with the same function as UMOV on 386+. If you use them together - something Intel probably didn't intend - you can dump the internal CPU state to memory on a regular non-bond-out chip. https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mode-and-f1-0f-04/ https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mo...
js8 21d ago
It's basically a convention. The alternative is to raise interrupts of course, but that might be application specific, or use other invalid instructions than the designated one, but they might work differently on other processor types.
- sweetjuly 21d ago
  There's a bit of convention and practicality The only thing you really need is that your "fatal error" instruction and "syscall" instruction can be reasonably discriminated without needing to set registers at the call site. Needing to set register to identify a fatal error is not great for code size, especially in languages that generate a lot of them (memory safe languages, mostly). Though, yes, convention does play a role. On ARMv8 you get both SVC <imm> and BRK <imm>. SVC and BRK raise different exception codes (which satisfies the "easy to distinguish requirement) but in principle you could just use BRK with a well-known immediate and eliminate the need for SVC since BRK's immediate is reported in the exception status register. And, anyways, if you have an SVC instruction and a BRK instruction, you may as well use the SVC instruction for syscalls since it's right there.
  - pm215 20d ago
    ARMv8 also gives you a a UDF imm, for a guaranteed undefined insn with an immediate payload. The reason to want a true UDF imm with an immediate comes down to it being pretty solidly guaranteed that it's going to turn into your language/OS equivalent of a SIGILL insn. In theory an OS could by convention allocate some subset of BRK space for arbitrary userspace purposes, but in practice none did, so trying to use BRK gets you dumped into a debugger, or doesn't have consistent behaviour. It's nice for userspace to have something that doesn't need active OS support.
    - mitxela 20d ago
      X86 has int3 for this purpose. Interrupt 3 is designated as debug breakpoint and a single-byte instruction raises it (or you can use int 3, two bytes)
omoikane 21d ago
Maybe because if the code wants to call the invalid opcode interrupt handler (INT6), it needs extra code to populate the flags and registers expected by that handler, whereas actually triggering an invalid opcode exception will get all those parameters populated automatically.
- thayne 20d ago
  And this is code that will (hopefully) almost never run, so you don't want it to take up much space in you your program, and especially cache lines.
- mitxela 20d ago
  It doesn't have to be the invalid opcode handler that you call. Prior to SYSCALL they picked one to be the system call handler. Windows 95 used illegal instructions because it was benchmarked to be the fastest fault.
adrian_b 20d ago
Already since Intel 8086, x86 has the instruction "INT vector_number", whose purpose is to allow software to invoke directly any of the many kinds of exception handlers or hardware interrupt handlers that are specified by the ISA or implemented by the hardware designer, which are normally invoked when various conditions arise, as determined by software execution or by I/O events. So you can invoke the handler of the invalid instruction exception with the INT instruction, but as another poster mentioned, the INT instruction alone is not enough for this, but you need to setup the stack in such a way so that it will contain the information expected by the exception handler, which requires multiple instructions. This kind of invocation may be acceptable when you write a test program for the invalid instruction exception handler, but it is not acceptable when you want to initialize some guard memory with values that will trigger the exception, to signal that your program has attempted to execute instructions from an area that should not be executable. Setting a memory area as non-executable through the access rights has only page granularity, so it is not useful when a page must contain both some executable code and some non-executable data. If Intel had not defined an official opcode that is guaranteed to remain unused forever, to be able to reliably trigger the invalid instruction exception, the workaround would have been for the user to reserve one of the 256 interrupt vectors for the invocation through software of the invalid instruction exception. For that vector, a simple handler could have been used, which would have setup the stack in the right way, before jumping to the invalid instruction handler. But this workaround would have had the disadvantage that any chosen interrupt vector could have conflicted with some choice made by the hardware designers of some computers, so it would have been required for it to be a configurable parameter of the operating system kernel, and also of the user applications that need it, like compilers, unless it would have been standardized by some organization. Just reserving an opcode at Intel and AMD was simpler, with no other requirements for standardization or changes in the existing software.
- rep_lodsb 20d ago
  #UD has the same stack frame as a software interrupt, there's no error code pushed. But most likely, executing INT 06 from ring 3 will generate a protection fault instead, since the gate descriptor would be set up to not be reachable from that privilege level. (exceptions that do push an error code couldn't be emulated at all using INT, since the error code is the last thing pushed by the CPU, after flags and return address)
fweimer 20d ago
I expect that UD2 stops instruction fetching (beyond the current block) and conversion to µops. A software interrupt or supervisor call should probably do neither because most of the time, these instructions eventually return and continue executing the next instruction.
- rep_lodsb 20d ago
  An interrupt or SYSCALL instruction could do anything, which includes remapping or overwriting the memory location it returns to. So no, these instructions can't be prefetched in any case.
fsckboy 20d ago
>you can raise software interrupts/exceptions exception handling requires that some unrelated region of memory is initialized and intact and ready to do the right thing, whatever that is, and that region is outside the scope of your control, it belongs to the operating system or the the embedded ROM, and it may not have been laid out to take care of your case. assembly/machine code is operating at a lower layer: "I don't know what larger thing I'm a part of, but I know I need to stop."
- rep_lodsb 20d ago
  If you don't know anything about the environment the code runs in, you can't rely on what action the undefined opcode handler will take either. (same for any other exception) Some operating systems used them for syscalls.
  - fsckboy 20d ago
    1. you can use the opcode, it's guaranteed. if it does something else, that's not on you. 2. you might know everything about the environments and that's how you know that different environments use different interrupt tables, but you want a code snippet that will not rely on that, so you use this guaranteed opcode.
    - rep_lodsb 17d ago
      Usually, you do know something about the environment that your code runs in. But in the case that you don't, causing an exception (whether "undefined opcode" or anything else) can't be guaranteed to terminate the process, because some operating systems actually did use it for other purposes. The assembly language equivalent of nasal demons :) https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003 https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...
asveikau 20d ago
It's common to use int3 for some of the scenarios mentioned in the article. (Like non-reachable code) This instruction is often used to trigger a break in the debugger.

by Neywiny 21d ago

I'm not much of an x86 person but on other architectures you can raise software interrupts/exceptions. Does x86 not have this or did those facilities not cover enough use cases?

349ru3h4f03 21d ago

x86 has... INT Ib INT1 INT3 INTO BOUND

userbinator 18d ago
Note that INT1 was originally called ICEBP before Intel finally documented it publicly (very recently).
- rep_lodsb 17d ago
  Yes, and it's not quite the same as a normal "INT 01h". It causes a debug exception, which may enter ICE mode if it is enabled (undocumented bit in DR7, or PMCR on Pentium), otherwise it invokes interrupt 1, but without checking the privilege level on the IDT entry, or the interrupt redirection bitmap in V86 mode. https://www.rcollins.org/secrets/opcodes/ICEBP.html https://www.rcollins.org/secrets/opcodes/ICEBP.html IIRC, older versions of the Linux kernel had a security bug because they didn't expect this to happen. ICE mode was sort of a precursor to SMM, but both also coexisted for a time with slightly different behaviour. It was introduced in the 286, where instead of ICEBP there was "STOREALL" (opcode 0F04). F1 on that processor was a prefix instead, with the same function as UMOV on 386+. If you use them together - something Intel probably didn't intend - you can dump the internal CPU state to memory on a regular non-bond-out chip. https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mode-and-f1-0f-04/ https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mo...

js8 21d ago

It's basically a convention. The alternative is to raise interrupts of course, but that might be application specific, or use other invalid instructions than the designated one, but they might work differently on other processor types.

sweetjuly 21d ago
There's a bit of convention and practicality The only thing you really need is that your "fatal error" instruction and "syscall" instruction can be reasonably discriminated without needing to set registers at the call site. Needing to set register to identify a fatal error is not great for code size, especially in languages that generate a lot of them (memory safe languages, mostly). Though, yes, convention does play a role. On ARMv8 you get both SVC <imm> and BRK <imm>. SVC and BRK raise different exception codes (which satisfies the "easy to distinguish requirement) but in principle you could just use BRK with a well-known immediate and eliminate the need for SVC since BRK's immediate is reported in the exception status register. And, anyways, if you have an SVC instruction and a BRK instruction, you may as well use the SVC instruction for syscalls since it's right there.
- pm215 20d ago
  ARMv8 also gives you a a UDF imm, for a guaranteed undefined insn with an immediate payload. The reason to want a true UDF imm with an immediate comes down to it being pretty solidly guaranteed that it's going to turn into your language/OS equivalent of a SIGILL insn. In theory an OS could by convention allocate some subset of BRK space for arbitrary userspace purposes, but in practice none did, so trying to use BRK gets you dumped into a debugger, or doesn't have consistent behaviour. It's nice for userspace to have something that doesn't need active OS support.
  - mitxela 20d ago
    X86 has int3 for this purpose. Interrupt 3 is designated as debug breakpoint and a single-byte instruction raises it (or you can use int 3, two bytes)

omoikane 21d ago

Maybe because if the code wants to call the invalid opcode interrupt handler (INT6), it needs extra code to populate the flags and registers expected by that handler, whereas actually triggering an invalid opcode exception will get all those parameters populated automatically.

thayne 20d ago
And this is code that will (hopefully) almost never run, so you don't want it to take up much space in you your program, and especially cache lines.
mitxela 20d ago
It doesn't have to be the invalid opcode handler that you call. Prior to SYSCALL they picked one to be the system call handler. Windows 95 used illegal instructions because it was benchmarked to be the fastest fault.

adrian_b 20d ago

Already since Intel 8086, x86 has the instruction "INT vector_number", whose purpose is to allow software to invoke directly any of the many kinds of exception handlers or hardware interrupt handlers that are specified by the ISA or implemented by the hardware designer, which are normally invoked when various conditions arise, as determined by software execution or by I/O events. So you can invoke the handler of the invalid instruction exception with the INT instruction, but as another poster mentioned, the INT instruction alone is not enough for this, but you need to setup the stack in such a way so that it will contain the information expected by the exception handler, which requires multiple instructions. This kind of invocation may be acceptable when you write a test program for the invalid instruction exception handler, but it is not acceptable when you want to initialize some guard memory with values that will trigger the exception, to signal that your program has attempted to execute instructions from an area that should not be executable. Setting a memory area as non-executable through the access rights has only page granularity, so it is not useful when a page must contain both some executable code and some non-executable data. If Intel had not defined an official opcode that is guaranteed to remain unused forever, to be able to reliably trigger the invalid instruction exception, the workaround would have been for the user to reserve one of the 256 interrupt vectors for the invocation through software of the invalid instruction exception. For that vector, a simple handler could have been used, which would have setup the stack in the right way, before jumping to the invalid instruction handler. But this workaround would have had the disadvantage that any chosen interrupt vector could have conflicted with some choice made by the hardware designers of some computers, so it would have been required for it to be a configurable parameter of the operating system kernel, and also of the user applications that need it, like compilers, unless it would have been standardized by some organization. Just reserving an opcode at Intel and AMD was simpler, with no other requirements for standardization or changes in the existing software.

rep_lodsb 20d ago
#UD has the same stack frame as a software interrupt, there's no error code pushed. But most likely, executing INT 06 from ring 3 will generate a protection fault instead, since the gate descriptor would be set up to not be reachable from that privilege level. (exceptions that do push an error code couldn't be emulated at all using INT, since the error code is the last thing pushed by the CPU, after flags and return address)

fweimer 20d ago

I expect that UD2 stops instruction fetching (beyond the current block) and conversion to µops. A software interrupt or supervisor call should probably do neither because most of the time, these instructions eventually return and continue executing the next instruction.

rep_lodsb 20d ago
An interrupt or SYSCALL instruction could do anything, which includes remapping or overwriting the memory location it returns to. So no, these instructions can't be prefetched in any case.

fsckboy 20d ago

>you can raise software interrupts/exceptions exception handling requires that some unrelated region of memory is initialized and intact and ready to do the right thing, whatever that is, and that region is outside the scope of your control, it belongs to the operating system or the the embedded ROM, and it may not have been laid out to take care of your case. assembly/machine code is operating at a lower layer: "I don't know what larger thing I'm a part of, but I know I need to stop."

rep_lodsb 20d ago
If you don't know anything about the environment the code runs in, you can't rely on what action the undefined opcode handler will take either. (same for any other exception) Some operating systems used them for syscalls.
- fsckboy 20d ago
  1. you can use the opcode, it's guaranteed. if it does something else, that's not on you. 2. you might know everything about the environments and that's how you know that different environments use different interrupt tables, but you want a code snippet that will not rely on that, so you use this guaranteed opcode.
  - rep_lodsb 17d ago
    Usually, you do know something about the environment that your code runs in. But in the case that you don't, causing an exception (whether "undefined opcode" or anything else) can't be guaranteed to terminate the process, because some operating systems actually did use it for other purposes. The assembly language equivalent of nasal demons :) https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003 https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...

asveikau 20d ago

It's common to use int3 for some of the scenarios mentioned in the article. (Like non-reachable code) This instruction is often used to trigger a break in the debugger.