19 lines
1.6 KiB
Plaintext
19 lines
1.6 KiB
Plaintext
1. Some interrupts receive a different "shape" of stack frame - the kernel pushes
|
|
an error code for some, but not for the others. We thus need individual handlers
|
|
that would make sure that what we have on the stack is consistent, and
|
|
then call one centralized function for that. The handlers additionally
|
|
are able to pass in a trap number to that centrallized function. This way, a lot
|
|
of code can be re-used.
|
|
|
|
Conceptually, each trap has a different semantic meaning. Thus, it makes no sense
|
|
to perform the same action for both traps - they don't mean the same thing.
|
|
|
|
2. The general protection fault occurs when a process can access memory, but not do something else with it. We do not want page faults to be trigger-able by users (this is the case for many other traps). Thus, when the user tries to invoke int 14,
|
|
it's not allowed to execute it from userspace, so it is thrown a general protection fault, which it then prints.
|
|
|
|
3. Unlike most other traps, the debugging trap should be possible to trigger from user code. If the "privillege level" is set to 0 in the IDT, when the INT3 occurs, the user does not have permission to call that interrupt,
|
|
and thus, a general protection fault occurs. In order to make it work correctly, the privillege level needs to be 3 (for userland).
|
|
|
|
4. It's probably so that users cannot deliberately trigger certain faults for malicious purposes. It doesn't make sense to trigger a page fault without properly setting up CR2, and even then, though I can't think
|
|
of anything right now, there's likely security issues that could arise if users can deliberately page fault their own process.
|