lamaster@ames.arc.nasa.gov (Hugh LaMaster) (05/03/89)
Has any attention been given to which of the new RISC architectures are truly virtualizable (in the strict VM sense)? (One reason that this is still interesting (to me) is because you can do certain capability/object things with virtual machines fairly efficiently.) Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
baum@Apple.COM (Allen J. Baum) (05/04/89)
[] >In article <24844@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >Has any attention been given to which of the new RISC architectures are truly >virtualizable (in the strict VM sense)? > >(One reason that this is still interesting (to me) is because you can do >certain capability/object things with virtual machines fairly efficiently.) You've aroused my curiosity. What can you do efficiently if your arhictecture is virtualizable? I'm posting this instead of replying, because other people are probably interested as well. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (05/04/89)
In article <30036@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >You've aroused my curiosity. What can you do efficiently if your arhictecture >is virtualizable? I'm posting this instead of replying, because other people >are probably interested as well. I have been told by an "expert" (i.e. I don't know enough about it to say anything that isn't in some way misleading, so I will avoid details) that virtual machines are the cheapest, most effective way known, to produce an operating system which is secure, with capabilities at the process level of granularity. You can also do it with special purpose hardware architectures, but (invoking the history of micros in the 80's) general purpose systems are always better if you can use them. In general, a special purpose market cannot finance the R&D necessary to stay competitive when technology is changing rapidly. So, the obvious answer is to use a general purpose machine. Well, I am told that you need virtual machines in order to build secure capabilities based systems, preferably with some sort of reasonably cheap shared memory facility (to do reasonably inexpensive message passing). Perhaps a net expert can enlighten us? Anyway, to determine if an architecture is virtualizable, you need a complete architectural definition handy. (It seems to be non-trivial to define an architecture clearly. Register to register instructions are easy, of course, but when you get to interrupts, cache coherency, restartable instructions, and combinations thereof, well...) I just don't have immediate access to the architectural definition of these new micros. Aside: You don't often find documents like the famous "Principles of Operation". I will avoid making specific comments, but some microprocessor manufacturers seem to think that an assembler manual is an architectural definition. In my experience, many traditional mainframe companies have been much more painstaking about defining and documenting their hardware architectures. But, I haven't seen the documents for all the current players. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
pcg@aber-cs.UUCP (Piercarlo Grandi) (05/07/89)
In article <24898@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: In article <30036@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >You've aroused my curiosity. What can you do efficiently if your arhictecture >is virtualizable? I'm posting this instead of replying, because other people >are probably interested as well. I have been told by an "expert" (i.e. I don't know enough about it to say anything that isn't in some way misleading, so I will avoid details) that virtual machines are the cheapest, most effective way known, to produce an operating system which is secure, with capabilities at the process level of granularity. Well, this is not entirely true. When you virtualize, you create a totally security kernel controlled "contained" environment. But, but you can do that with a pseudo machine virtualization, which is usually much easier. Your expert surely has in mind the secure VM/370. Well, they had a problems with that, because most of the security problems of VM/370 lie precisely in the virtualization of the grottiest details of virtualizing an exact rendition of the real machine (i.e. channel programs for the 370). [ .... ] Well, I am told that you need virtual machines in order to build secure capabilities based systems, preferably with some sort of reasonably cheap shared memory facility (to do reasonably inexpensive message passing). First, a note on shared memory: hard to deal with it from a security kernel point of view. Again, it is true in part; you need to provide a virtual machine, but this need not be (and let me add, had better not be) an exact virtualization of the real machine, especially as, as you correctly observe, Anyway, to determine if an architecture is virtualizable, you need a complete architectural definition handy. (It seems to be non-trivial to define an architecture clearly. [ ... ] Aside: You don't often find documents like the famous "Principles of Operation". I will avoid making specific comments, but some microprocessor manufacturers seem to think that an assembler manual is an architectural definition. [ ... ] As a final note: I have designed (a lot of time ago) and am implementing (finally, and slowly) a security kernel that does create software virtual machines (without shared memory). It is capability based, of course; there have been others efforts, usually under the "object oriented OS" label, starting from CAL-TSS. Recent ones are Ra, Clouds, Elmwood/Psyche, Accent/Mach, KeyKos, ... They all run on conventional architectures. But note, the only A1 system around is Honeywell's SCOMP, that extends in hardware (via a special MMU) a conventional architecture, to support fine granularity of protection (which is not practical using software alone). Maybe this is the better compromise -- use a stock CPU, add an ad-hoc capability MMU (if you can afford to do it). -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk