trt@rti-sel.UUCP (Tom Truscott) (12/10/84)
> The main attractiveness of VM for secure systems is that VM itself is a > very limited system, concerned almost solely with partitioning ... This argument is compelling. After all, VM concerns itself with 'not sharing' (security) whereas MVS concerns itself with 'sharing' (insecurity). And VM's task is conceptually much simpler. So I was surprised a few years ago to read a Datamation (?) article by an IBM computer security person who said that they 'warranted' the security of MVS but not VM. That means IBM will fix any security hole found in MVS. >From what I have heard MVS (with RACF) is much more secure than MVF or MVT but only in the sense that security flaws are much more obscure and difficult to exploit. Perhaps VM, though potentially secure, comes up short since VM users insist on sharing (minidisks, whatever) and the hacks^H^H^H^Hmechanisms for so doing have security flaws. Tom Truscott
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (12/10/84)
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@USC-ECL.ARPArcd@opus.UUCP (Dick Dunn) (12/14/84)
> 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?
karl@cygnet.CYGNETSYSTEMS (Karl Danz) (12/18/84)
> 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. The way I heard it, VM came into being to fill a need within IBM: they wanted to let lots of people do operationg systems development work without handing over a megabuck machine to every one of them. CMS was to be nothing more than a file system, an editor, and a few other tools with which to do this work. That VM was pried from IBM by customers who reasoned that there MUST be more to this world than MVS, and that VM has flourished, speaks well of it. Most of the problems which have been identified in this discussion arise from the difference between VM's designed use and its real (meaing current day) use. It's still the only way to go for developing and testing 370 architecture operating systems. I can certainly think of one other major operating system which is now being used for things the original authors would never have dreamed of! Karl Danz Cygnet Systems ...!hplabs!cygnet!karl
rcd@opus.UUCP (12/19/84)
> > 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. > > The way I heard it, VM came into being to fill a need within IBM: OK, OK--I (>>) was being just a teeeeeny bit facetious, and somewhat unfair, too. Specifically, VM was not developed within IBM, though I suppose they should get credit for eventually coming around to making it a product. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Nothing left to do but smile, smile, smile.
eager@amd.UUCP (Mike Eager) (12/20/84)
> So I was surprised a few years ago to read a Datamation (?) article > by an IBM computer security person who said > that they 'warranted' the security of MVS but not VM. > That means IBM will fix any security hole found in MVS. > > From what I have heard MVS (with RACF) is much more secure than > MVF or MVT but only in the sense that security flaws are much more > obscure and difficult to exploit. Perhaps VM, though potentially secure, > comes up short since VM users insist on sharing (minidisks, whatever) > and the hacks^H^H^H^Hmechanisms for so doing have security flaws. > Tom Truscott MVS is substantially more secure than MVT or MFT or the other OS/360 or DOS operating systems, having plugged most of the glaring holes. Sometime I'll tell about how I used to tell the operating system to use my open exit, then I'd finagle getting returned in supervisor mode. Ah, history. There was an IBM Systems Journal some years ago which had a set of articles about VM security. I have the feeling that it should be quite easy to verify that VM is secure, in the sense that one user cannot obtain or alter the data of another user without permission. Sharing mini-disks requires that permission.
henry@utzoo.UUCP (Henry Spencer) (12/22/84)
> ... I have the feeling that it should be quite easy to verify > that VM is secure, in the sense that one user cannot obtain or alter the data > of another user without permission. Sharing mini-disks requires that > permission. That's exactly where the problem lies: sharing. Isolation is easy (well, relatively easy) to verify. Controlled sharing is the hard part. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
mwm@ea.UUCP (12/27/84)
/***** ea:net.unix-wizards / opus!rcd / 6:57 pm Dec 21, 1984 */
OK, OK--I (>>) was being just a teeeeeny bit facetious, and somewhat
unfair, too. Specifically, VM was not developed within IBM, though I
suppose they should get credit for eventually coming around to making it a
product.
--
Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
...Nothing left to do but smile, smile, smile.
/* ---------- */
Urk - I just got more confused. I was under the impression that VM had been
developed at an IBM research lab in the UK, much as Unix was developed in
an AT&T research lab.
My reference books are packed, so I can't chase it down. Could somebody
enlighten me?
<mikekel@ea.UUCP (12/27/84)
As I recall, VM was indeed developed at the IBM research labs in the UK, but as an off-time project. IBM resisted release of VM as much as they could, but people started getting their hands on it anyway. IBM released it just so they could charge to support it. VM was a fairly significant embarassment to the company back in '78 or '79 for this reason. Ken
dsg@mhuxi.UUCP (David S. Green) (12/28/84)
[] As I recall, CMS stood for Cambridge Monitor System and IBM re-named it Conversational Monitor System. I believe it was developed by some MIT guys who went on to form a company called NCSS ( now D&B Computing or something ). CMS was a "friendly" 1960s timesharing system that runs under VM (Virtual Machine). Under VM you can run any operating system you want, as long as you have the 370 code for it. CMS is one option. CP (Control Program) is also part of the package as are things like BSPP. IBM developed VM, CP and enhanced CMS. VM is a system control program. It manages the resources of an IBM 370 type computer in such a way that multiple users have a functional simulation of a computing system (a virtual machine) at their disposal. Note that VM can run many different OSs concurrently. CP executes in a real machine controlling the resources of that machine. CP is used to create concurrent virtual machines. CMS is a single user OS that can execute in one or more virtual machines. CMS is considered to be a timesharing OS. Hope that clarifies the discussion. David S. Green Bell Labs ..mhuxi!dsg 201-564-2000 > /***** ea:net.unix-wizards / opus!rcd / 6:57 pm Dec 21, 1984 */ > OK, OK--I (>>) was being just a teeeeeny bit facetious, and somewhat > unfair, too. Specifically, VM was not developed within IBM, though I > suppose they should get credit for eventually coming around to making it a > product. > -- > Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 > ...Nothing left to do but smile, smile, smile. > /* ---------- */ > > Urk - I just got more confused. I was under the impression that VM had been > developed at an IBM research lab in the UK, much as Unix was developed in > an AT&T research lab. > > My reference books are packed, so I can't chase it down. Could somebody > enlighten me? > > <mike
andrew@orca.UUCP (Andrew Klossner) (12/31/84)
Not that many Unix inhabitants care, but here's two more cents worth
about VM/370 before the end-of-Xmas news rush ...
"(Virtual Machine). Under VM you can run any operating system
you want, as long as you have the 370 code for it. CMS is one
option. CP (Control Program) is also part of the package ...
IBM developed VM, CP and enhanced CMS. VM is a system control
program. It manages the resources of an IBM 370 type computer
in such a way that multiple users have a functional simulation
of a computing system (a virtual machine) at their disposal.
Note that VM can run many different OSs concurrently. CP
executes in a real machine controlling the resources of that
machine. CP is used to create concurrent virtual machines.
CMS is a single user OS that can execute in one or more virtual
machines. CMS is considered to be a timesharing OS ... Hope
that clarifies the discussion."
Some corrections. VM/370 is the name of a system software package
which consists primarily of two components: CP and CMS. CP is the
kernel running on the real machine (unless it's running under itself
...). It is the part of VM/370 that presents several virtual machine
environments. It is responsible for fielding traps and interrupts,
doing resource allocation (like scheduling), and other "kernel" jobs.
There is some user interface in CP, but not much ... it's mostly of the
"simulate a front panel" variety, like the command to boot an operating
system in your virtual machine.
CMS is a single-user IBM 370 operating system. When it runs
stand-alone on a 370, it supports a single user. Several instances of
it can be running under CP, each in a distinct virtual machine. Since
CMS doesn't have to support more than one user, it needn't be concerned
with issues of resource fairness or protection.
Thus, there is no distinct piece of the package called "VM"; the name
refers to the entire system. Often users of such a system will
use the terms "VM" and "CP" interchangeably. And the beauty of CMS is
that it is *not* a timesharing OS.
Incidentally, modern versions of CMS will not run stand-alone on a real
computer. For reasons of efficiency, CP allows programs running in
virtual machines to use an additional means of requesting services,
implemented with the "diagnose" instruction (which on a real machine
causes model-specific results for hardware maintenance, and is useless
to production software). For example, one variant of "diagnose" means
"read a record from the tape drive, block this virtual machine until
complete." This is a good deal more efficient than going through the
standard hardware sequence of events: start I/O; wait for an interrupt;
handle the interrupt; test the I/O state; etc. CMS does all its
standard I/O through diagnose, and so can no longer execute on a bare
machine.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]