CS-444/jos
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update lab3 answers

Browse Source
This commit is contained in:
Danila Fedorin 2019-05-13 23:05:00 -07:00
parent 5e04fb305e
commit 7965d399dc
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
answers-lab3.txt
View File

@ -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, 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. 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.