Update lab3 answers
This commit is contained in:
parent
5e04fb305e
commit
7965d399dc
@ -10,3 +10,9 @@ 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.
|
||||
|
Loading…
Reference in New Issue
Block a user