geof@imagen.UUCP (Geoffrey Cooper) (01/22/87)
In the 68000, the move from sr instruction is not a privileged instruction. In the 68010 and 68020 a new instruction exists, move from ccr, which just moves the condition codes out of the SR, the other bits being zero. In the 68010 and 68020 move from SR is a privileged instruction. This appears to be a crock. It means that simple assembly language routines must be different for 68010 and 68020. It significantly affects the portability of code between them (especially when compilers like to generate code to save the condition codes on the stack). My question is why the lords of 68000-land did this? Presumably there is some lack or portability or security loophole in allowing a user program to look at the SR. I don't know what it is. Does anyone else? - Geof Cooper IMAGEN
stever@cit-vax.Caltech.Edu (Steve Rabin ) (01/22/87)
In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >My question is why the lords of 68k-land did this? Presumably >there is some lack or portability or security loophole in allowing >a user program to look at the SR. > >- Geof Cooper > IMAGEN Motorola did this to facilitate debugging new operating systems. When the system under development reads the SR, a trap is generated, allowing the debugger to lie about status bits to the proto-OS. Steve Rabin
mark@markshome (mark weiser) (01/23/87)
>In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >My question is why the lords of 68k-land did this? Presumably >there is some lack or portability or security loophole in allowing >a user program to look at the SR. > >- Geof Cooper > IMAGEN This is a very nice thing motorola did for the 68010 and 68020. It makes the processor virtualizable. It is now possible to write a hypervisor for a 680x0 (x!=0) which can run binary images of other operating systems that think they have the whole machine, and there are no non-privileged instructions which that other O.S. can use to tell that it is being hypervised. If it tries to tell, by using a privileged instruction, it gets trapped and the hypervisor can lie. -mark Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
mark@markshome (mark weiser) (01/23/87)
In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >In the 68010 and 68020 move from >SR is a privileged instruction. >This appears to be a crock. >My question is why the lords of 68000-land did this? Actually, in my opinion, not doing it this way is a crock. A similar instruction on the 80386 is NOT privileged, and that means the 80386 cannot be fully virtualized, and that means that no one can be sure of writing an operating system which will be able to transparently run 80386 binaries, (such as 80386 MS-DOS, should there ever be such a thing.) So everyone just has to sit on their hands waiting and hoping that when Microsoft does release such a thing, it will not use any of these spoof-proof instructions to see if it being hypervised. I could speculate that Microsoft, IBM, and Intel conspired to build the 80386 this way, rather than making it virtualizable, for devious market control reasons. But I won't. -mark Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
davet@oakhill.UUCP (01/23/87)
In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >In the 68000, the move from sr instruction is not a privileged >instruction. In the 68010 and 68020 a new instruction exists, >move from ccr, which just moves the condition codes out of the >SR, the other bits being zero. In the 68010 and 68020 move from >SR is a privileged instruction. This was done to support virtual machine capability. User code must not be allowed to examine any privileged resource without control passing to the supervisor first for validation, substitution replacement or denial. >This appears to be a crock. It means that simple assembly >language routines must be different for 68010 and 68020. It >significantly affects the portability of code between them >(especially when compilers like to generate code to save the >condition codes on the stack). I was not happy myself with the decision, but there are ways around it. First, an O.S. can simply patch the move sr to a move ccr by setting one bit on in the instruction. That way, you only have a penalty the first time the move sr is hit in memory. Thereafter it runs at raw CPU speed. Another solution is to have code in the privilege exception handler which dynamically builds a move ccr equivalent followed by a jump back into the program on the stack which is RTEd to. This handles the rare case where a move sr is in rom and cannot be altered. The routine is small and is published in a Motorola Technical document. -- Dave Trissel Motorola, Austin. {seismo,ihnp4}!ut-sally!im4u!oakhill!davet
lamaster@pioneer.arpa (Hugh LaMaster) (01/23/87)
In article <5158@mimsy.UUCP> mark@markshome.UUCP (mark weiser) writes: >In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >>In the 68010 and 68020 move from >>SR is a privileged instruction. >>This appears to be a crock. >>My question is why the lords of 68000-land did this? > >Actually, in my opinion, not doing it this way is a crock. A similar >instruction on the 80386 is NOT privileged, and that means the 80386 >cannot be fully virtualized, and that means that no one can be sure of Is there a commercially available hypervisor for the 68010 and 68020? I assume that Motorola has one for internal use, but I haven't heard of anything available for user systems. It is a great idea, though. Hugh LaMaster, m/s 233-9, UUCP: {seismo,hplabs}!nike!pioneer!lamaster NASA Ames Research Center ARPA: lamaster@ames-pioneer.arpa Moffett Field, CA 94035 ARPA: lamaster%pioneer@ames.arpa Phone: (415)694-6117 ARPA: lamaster@ames.arc.nasa.gov "He understood the difference between results and excuses." ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
blarson@castor.usc.edu.UUCP (01/24/87)
In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >In the 68000, the move from sr instruction is not a privileged >instruction. In the 68010 and 68020 a new instruction exists, >move from ccr, which just moves the condition codes out of the >SR, the other bits being zero. In the 68010 and 68020 move from >SR is a privileged instruction. [...] >My question is why the lords of 68000-land did this? The 68k manuals say this was to allow virtual machine type operating systems to be emplemented. This by itself is not a bad idea, but I think it should have been implemented by making the move ccr instruction on the 68010 and 68020 have the same opcode as the 68000 move sr instruction. This way only programs using the upper byte of the sr would need to be changed. (Mainly OS's.) -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
dpm@k.cs.cmu.edu.UUCP (01/25/87)
The MOVE SR, <ea> instruction was made privileged in the later MC680X0
family members in order to support the "virtual machine" concept.
If the proper trap handlers are installed, the operating system can
"intercept" privileged instructions and effectively "fool" the user code
into thinking it is running in supervisor mode. Among other things, this
allows OS developers to debug new versions of the operating system while
running under an older version.
It is my understanding that the instruction was not privileged in the
original MC68000 because of an oversight.
------------------------------------------------------------------------------
David P. Maynard
Department of Electrical and Computer Engineering
Carnegie Mellon University
(412) ANT-FEED
ARPA: dpm@faraday.ece.cmu.edu
UUCP: {sun,seismo,...}!faraday.ece.cmu.edu!dpm
------------------------------------------------------------------------------jdg@elmgate.UUCP (Jeff Gortatowsky) (01/25/87)
My understanding of the Move From STATUS reg difference on the 68k vs.
the 010 and 020 is that this one simple difference allows the
implementation of virtual machines. This is where each process thinks
it has it's OWN operating system that is running in supervisor mode but
indeed is just another task under some other master executive. If you
were allowed to 'see' the status register you'd find out that your so
called operating system is really not in supervisor mode, something a
virtual machine concept does not tolerate. Instead, the REAL master
operating system traps the move status register instruction and gives
your fake operating system the impression it's in supervisor mode by
setting the S/U bit in the copy it returns.
I hope I haven't explained this too poorly. I'm not an OS expert but
this is what Motorola told me in an 020 training class.
--
Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
<Kodak won't be responsible for the above comments, only those below>