VM/370 Security (and performance)

[Dick Dunn]

> 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...

Hmmm...I've seen 40% of a CPU lost to VM--by which I mean a 40% performance
loss compared to running the (sub)system in native mode.  I guess it
depends on what you consider "acceptable".

>...
> Finally, most 370s (and successors) have VM-assist microcode to handle the
> majority of the pseudo-privledged operations without all the traps.

In other words, IBM is in a position of having botched the software so
badly that they have to hack the hardware to fix the mess.  (Probably
easier than fixing the software, though...)  Actually, VM-assist microcode
is, technically, a mediocre solution to the wrong problem--but in marketing
terms, it's a brilliant ploy:  It gives IBM a jump on the compatible CPU
manufacturers by being able to fix the hardware for the software
deficiencies.

> 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.

In other words, all of the peripheral resources of a single machine get
chopped up into pieces which are now subject to two levels of contention:
The users contend within their systems, and the systems contend within VM.
CMS mini-disks are a good example--you can hide disk space so there's
plenty free in the system as a whole but often none available to users who
need space.

I'm grateful to the colleague who finally gave the most reasonable
explanation of VM to me:  IBM couldn't figure out how to build a multi-user
shared system, so they found something that would let single-user systems
battle it out in a machine.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Are you making this up as you go along?