VM/370 Security

[Darrel VanBuer]

While VM 370 gives the appearance of a whole machine to each user (and client
operating system), in fact it does not.  E.g. when a client OS "enters"
sepervisor state, it really sets a flag in VM that the client "believes" it's
in supervisor state, and restores the machine to user state.  When the client
OS (tries) to execute a privledged instruction, it traps back to VM, gets
tested for no harm to the VM environment, VM does the privledged operation
and resumes execution.
This sounds horrible in performance, but is usually acceptible for several
reasons.  First, most OSs actually do few privledged operations.  Second, VM
is not threatened by all privledged ops, so many of the checks are short.
Finally, most 370s (and successors) have VM-assist microcode to handle the
majority of the pseudo-privledged operations without all the traps.
I/O is also virtualized under VM (e.g. printers are usually virtual devices
eventually spooled to a real VM printer), CMS "disks" are usually only
portions of some real disk.  I/O is a privledged operation, so VM limits
and modifies that too.
The main attractiveness of VM for secure systems is that VM itself is a
very limited system, concerned almost solely with partitioning the real
resources among the client operating systems.  Even though MVS is a huge
piece of software (and thus unavoidably full of bugs and bits of archaic
misdesign from 1960s), when run as a VM client, it's isolated from all other
users in other VM partitions. VM presents a much less formidable piece of
code to sucure.

-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
VANBUER at USC-ECL.ARPA