answers-lab3.txt

CSE P 551: Operating Systems (Autumn 2014)
Project 3: User Environments
Jeff Weiner (jdweiner@cs.washington.edu)
Myles Jordan (mylesj2@cs.washington.edu)
November 4th, 2014


What we did to solve the exercises:

To set up user environment handling, we filled in the missing gaps in the
environment initialization and management functions, which allowed JOS to enter
(but not exit) user mode.  To enable leaving it, we set up an interrupt
descriptor table to tell our processor what functions to run when various
interrupts need to be caught.  After setting up the IDT, all that remained was
the individual trap handlers.

Jeff completed exercises 1, 2, 9, and 10, and Myles completed exercises 4, 5,
6, 7, and 8.


Challenges completed:

None.


Questions & Answers:

1.  What is the purpose of having an individual handler function for each
    exception/interrupt?  (i.e., if all exceptions/interrupts were delivered to
    the same handler, what feature that exists in the current implementation
    could not be provided?)

There are two important features that are enabled by having individual handlers
for each trap. The first is that this allows the setting of the Descriptor
Privilege Level (DPL) per trap, allowing some interrupts to be generated by user
mode code, and other only by the kernel. The other feature that is enabled is
the passing of an Error Code to some interrupts, but not others; if there was
a common handler, it would be much harder to handle the differing length of
the set of parameters.


2.  Did you have to do anything to make the user/softint program behave
    correctly?  The grade script expects it to produce a general protection
    fault (trap 13), but softint's code says int $14.  Why should this produce
    interrupt vector 13?  What happens if the kernel actually allows softint's
    int $14 instruction to invoke the kernel's page fault handler (which is
    interrupt vector 14)?

All that is necessary for the softint program to produce a general protection
fault is that the DPL of the interrupt be set to zero. That way, when a user
mode program attempts to generate the interrupt, the hardware will block it due
to insufficient privilege level, and generate a general protection fault
instead.

If the kernel allowed arbitrary user mode programs to generate page faults then,
at best malicious code could execute a DoS attack against the OS, or worst it
might be possible to force the kernel to map arbirary memory into the processes
address space, depending on the design of the kernel.


3.  The break point test case will either generate a break point exception or a
    general protection fault depending on how you initialized the break point
    entry in the IDT (i.e., your call to SETGATE from trap_init).  Why?  How do
    you need to set it up in order to get the breakpoint exception to work as
    specified above and what incorrect setup would cause it to trigger a
    general protection fault?

For int3 to be able to be called directly from user mode, the DPL for the
interrupt must be set to 3 so it can be called from Ring 3 code. If that is not
done, and the DPL is instead set to 0, then the user mode code will be unable
to access the gate, and a general protection fault will be generated instead.


4.  What do you think is the point of these mechanisms, particularly in light
    of what the user/softint test program does?

Clearly, these protections are intended to prevent malicious or malfunctioning
user mode code from generating interrupts which may negatively affect the
operation of the OS.