1.  Solution: Many answers are possible. User-level access to
privileged instruc- tions would allow a malicious process to directly
perform I/O operations that could read or modify anyone’s files on
disk. User-level access to physical memory would allow a process to
overwrite data structures in another process. User-level ability to
disable timer interrupts would allow a buggy process to loop forever,
never yielding the processor.  

2.  Solution: The scripts must be constrained in all the same ways as
untrusted application code must be constrained: they cannot be allowed
to increase their own privileges, they need to be limited to accessing
only their own data struc- tures, and they need to be prevented from
looping forever. They also need to call into the browser only at
well-defined and bullet-proof entry points. 

3. Solution: Any security and reliability issues.  Ex) a malicious
user can set the stack pointer to jump into arbitrary kernel cod e or
user code!

4. Solution: Create code and run

5. Solution: One can simulate a system call trap by executing any
instruction that causes a hardware exception, such as to powerdown the
computer.  

6. Solution: Interrupts notify the operating system about asynchronous
events.  On a multiprocessor, the operating system could simulate
device interrupts by using one processor to poll devices to see if an
event has occurred on that device. Simulating timer interrupts — to
regain control of the processor from a runaway process — is
harder. The operating system would need to simulate the application
execution instruction by instruction, so as to periodically check
whether it needs to invoke the timer interrupt handler.