flat assembler
Message board for the users of flat assembler.

Index > Main > x86 distinguish between trap and fault.

Author
Thread Post new topic Reply to topic
MaoKo



Joined: 07 May 2019
Posts: 81
Location: Paris/French
MaoKo
Hello. Following this definition of trap:
Quote:

The CS and EIP values stored when the trap is reported point to the
instruction dynamically after the instruction causing the trap. If
a trap is detected during an instruction that alters program flow,
the reported values of CS and EIP reflect the alteration of program
flow. For example, if a trap is detected in a JMP instruction, the
CS and EIP values pushed onto the stack point to the target of the
JMP, not to the instruction after the JMP.

I would like to known if it's true to say that in x86 (in real mode and other as well) int = trap?
But from this defintion other things than the int-kind (int3, into) instruction can raise trap as well.
And if my guess is right, how can you known if an ISR was invoked because of an trap/fault?
So for instance, I want to write an ISR for #DE which print something when it's invoked by an int $00 or other thing when divide by zero occurs.
The only way I see is to decode the instruction pointed by CS:IP.
But is there a more "elegant" solution?
Post 26 Sep 2020, 01:34
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3073
Location: vpcmipstrm
bitRAKE
Software generated exceptions don't clear the interrupt flag.

(This question should probably be in OS Construction.)

_________________
¯\(°_o)/¯ unlicense.org
Post 26 Sep 2020, 13:45
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 471
Location: Czech republic, Slovak republic
Feryno
CPU manual clearly says for every exception whether it is fault or trap type. So knowing the interrupt vector number tells you whether fault or trap.
Int 01 (debug exception) may cause both, depending on situation, you can distinguish them by checking the value of DR6 and note that when DR6 is clear and no one bit set, then it was icebp hexa opcode F1.
There are also abort type of exception.
#DE is always fault type of exception, the faulting instruction does not complete so CS:IP is pointing to the faulting instruction.
When you execute int 00 (hexa opcode CD 00) then at first CPU performs various checks (e.g. when executed from ring3 whether it does not violate permissions and if it violates then no #DE generated but #GP generated). When this is caused by an exception then it is always delivered through IDT and CPU does not perform privilege checks. So the same vector may be executed on an exception as well as an execution of appropriate INT instruction. For every fault you can decode the instruction at CS:IP and see that it was hexa opcode like CD XX. For traps decoding CS:IP is useless, but there are only very few of traps. Also note that int 03 may be triggered by instruction int3 (hexa opcode CC) as well int 03 (hexa opcode CD 03), here is also the difference that the CD instruction is privilege/permission checked and for the CC the IOPL is not checked. Some exceptions push error code, but when you execute appropriate int (CD XX) instruction then the error code is not pushed so your interrupt handler must care of it to correctly resume the execution (using IRET/IRETQ) so sometimes you must remove the pushed error code from the stack before returning from interrupt and sometimes not. Also note that in IDT descriptor you can define for every interrupt vector whether it is handled through an interrupt gate (then IF is cleared when entering your interrupt handler) or trap gate (IF unaffected).
Post 26 Sep 2020, 18:51
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
MaoKo



Joined: 07 May 2019
Posts: 81
Location: Paris/French
MaoKo
Ok. Thank you for yours responses. These was of great help to me. But my definition of trap is therefore incorrect because only `int` can trigger it (except for the debug exception of course).
And, I've just tested it:
Code:
  xor cl, cl
  cs ss ds es fs gs div cl
  rep div cl
  ; db $66, $67, ...
    

theses prefix need to be handled as well. I'm not sure about the rep because normally it's an undefined behavior but on my machine it's like a nop.
It's been a long time that no one told me about the icebp instruction Wink.
I'm almost forgotten it.
Post 27 Sep 2020, 07:10
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 872
Location: Belarus
DimonSoft
MaoKo wrote:
I'm not sure about the rep because normally it's an undefined behavior but on my machine it's like a nop.

Being a nop is a perfectly valid case of undefined behaviour for an instruction.
Post 27 Sep 2020, 13:29
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17892
Location: In your JS exploiting you and your system
revolution
It's one of those weird things about x86 instruction coding. Not all of the ~256^15 possible byte sequences can be accounted for in the decoder circuit. So the makers just throw their hands up in the air and say: fsck it, anything we can't figure out is undefined. It might be nop, it might hang, it might zero the entire RAM, it might overheat and burn, ...

Same for C also, so much undefined behaviour.
Post 27 Sep 2020, 14:03
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 872
Location: Belarus
DimonSoft
revolution wrote:
It might be nop, it might hang, it might zero the entire RAM, it might overheat and burn, ...

Free pizza would be a better option though Smile
Post 27 Sep 2020, 20:56
View user's profile Send private message Visit poster's website Reply with quote
MaoKo



Joined: 07 May 2019
Posts: 81
Location: Paris/French
MaoKo
revolution wrote:

it might overheat and burn, ...

There were rumors in the past, where hacker was able to explode monitor with undefined behavior.
But I didn't known for the cpu lol.
Image
Post 27 Sep 2020, 23:04
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1565
Furs
DimonSoft wrote:
MaoKo wrote:
I'm not sure about the rep because normally it's an undefined behavior but on my machine it's like a nop.

Being a nop is a perfectly valid case of undefined behaviour for an instruction.
Note that they have repurposed rep prefixes to preserve compatibility with old CPUs and giving new features to new CPUs.

Like the 'pause' instruction, or the 'xacquire' prefix.
Post 28 Sep 2020, 20:34
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.