lab3-questionary.txt

=== This template file contains questions you need to answer.
=== Fill your answers on appropriate blank lines only.
=== Don't start any line with three equal signs "===".
=== Don't edit any lines starting from three equal signs.
=== Use C notation to write numbers: 42 for decimal, 0x2a for hexadecimal.
=== We may check most of the answers automatically, so "forty two" or
=== "26+16" won't work for this example. Spaces are mostly ignored, so
=== "  42  " is OK (without quotes of course). 
=== When asked to specify address & instruction, do it in the form of
=== gdb output "ADDRESS: INSTRUCTION", for example "0x7c26:  or  $0x1,%eax"
=== Don't make lines longer than 80 characters. You don't need to fit your
=== answer in a single line, you can start a new line at will.
=== However, when asked to fill "a table" make each table raw a single line.

=== Q In Exercise 4, can the function 'trap' ever return?
===   (yes/no)
no


=== Q 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?)
===   (free form, 1 sentence)
Kernel protection, by having multiple entry points we can decide on the 
CPL required to enter for each function and prevent malicious programs 
from gaining access to protected kernel code.


=== Q Did you have to do anything to make the user/softint program
===   behave correctly?
===   (yes/no)
no


=== Q 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? 
===   (free form, 1 sentence)
Because we tried to invoke a trap without the required CPL, meaning
we didn’t have permission to run int $14 from our code(user mode) so
we raised the protection guard trap instead of our desired trap.


=== Q 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)?
===   (free form, 1 sentence)
The user could cause page fault at will which will make a protection
breach in the kernel and could let the user change its behavior.


=== Q 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 idt_init). Why? How did you need to set it 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?
===   (free form)
We need to set it to DPL=3 for it to cause a break point from user
code, if we had set it to DPL = 0 it would cause a general protection
fault because we won’t have permissions to call the trap from user.


=== Q What do you think is the point of these mechanisms, particularly
===   in light of what the user/softint test program does? 
===   (free form, 1 sentence)
the purpose of these mechanisms is to protect the kernel code
from the user using kernel services which are not safe and could
become a protection breach.


=== Q In Exercise 9, what causes the page fault which panics the
===   kernel when running user/breakpoint?
===   (free form, 1 sentence)
Trying to print the params to libmain function we accessed unmapped memory
above user stack 

====================================================================
=== Q What challenge(s) have you chosen to implement? (specify
===   challenge numbers separated by spaces, if more than one)
2

=== Q If the challenge requires changing the kernel source, list the
===   files which you have changed/added during implementation.
===   (one file per line, relative to lab directory containing .git/)
kern/monitor.c
kern/monitor.h
kern/trap.c


=== Q Describe you solution.
===   (free form, up to 500 words, don't need to use all 500!)
We implemented the continue, si commands.
for the continue command we first checked that the current environment 
is running (as would returning from trap() would do) and called env_run to
continue from where we left.

As for si command, we first raise the TF flag in the curenv eflags, thus making
sure that after the next command we will call and the DEBUG interrupt (this is
what the TF flag does). then from the DEBUG interrupt we, after turning off the 
flag), call back to the monitor so we can continue using si.
We need to turn off the TF flag once we handle DEBUG to prevent DEBUG from firing 
again when not required.

We checked our code by viewing the printed eip and verifying it’s advance in a single 
step each time when using si or simply continuing the run fully with continue.