1.8: (a), (c), and (d) should only be allowed in kernel mode.  Some
would add (b) to that list, because it makes the machine easier to
virtualize.

1.13: Different operating systems do this in different ways.  On
Unix-like systems, data to be written is copied to kernel memory, if
buffers are available; the application thus does not block.  If
buffers are not available, the application will block until they
are, but the actual write is done without blocking the application.
On other operating systems, data is written directly from user
memory, to avoid the expense of the copy.  The application may or
may not block, depending on whether or not the OS permits
asynchronous writes.  If it doesn't block, there is the very
interesting question of what happens if the user program modifies
the data -- it's a race condition, but it way result in different
data being copied to the disk than was there originally.

2.3: Interrupt handlers have to do things like save and restore
registers, and --- perhaps --- read various other CPU state
registers.
These concepts cannot be expressed in high-level languages.

2.4: The application's stack is under the control of the
application. The pointer may not be correct or legal, and there may
not be room on the stack.  Beyond that, the kernel may be dealing
with confidential data; if the user's stack is used, this could be
inspected by the user process after the interrupt.