Hi everyone,
I've entered the magic of interrupts and to test if my IDT works I implemented a division_error handler. Everything works fine but now I have a doubt. Now I have only a kernel, so everything works at RING 0. But in the future, when an userspace program will cause a division_error, how can I know if the division error was generated by the kernel or the userspace program? Because if the kernel generates it, i will panic, but if the fault is produced by the user program its enough to kill the program. I need to take this into account or for now its good like that? Thanks for your help
Understanding Fault Handlers
Re: Understanding Fault Handlers
How about checking the return value on the stack?
-
- Posts: 3
- Joined: Sun Dec 15, 2024 3:21 am
Re: Understanding Fault Handlers
You are suggesting that I can use the cs register pushed on the stack to understand who generated the fault?
Re: Understanding Fault Handlers
I was suggesting the IP value, but CS would work too.
-
- Posts: 3
- Joined: Sun Dec 15, 2024 3:21 am
Re: Understanding Fault Handlers
Thank you so much for the help!
Re: Understanding Fault Handlers
Checking the DPL of the CS pushed to the stack is how Linux does this. In protected mode, this is a necessary prerequisite to figuring out if SS and ESP have been pushed as well.
In long mode, this is also how it figures out whether to execute "swapgs" or not. Except in the critical error handlers (NMI, machine check, and double fault), because those can occur anywhere, so they must check the validity of the GS base by reading it out directly.
In long mode, this is also how it figures out whether to execute "swapgs" or not. Except in the critical error handlers (NMI, machine check, and double fault), because those can occur anywhere, so they must check the validity of the GS base by reading it out directly.
Carpe diem!