Update lab3 answers

answers-lab3.txt

@@ -0,0 +1,18 @@
+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.