Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mgm.mit.edu!wolfgang
From: wolfgang@mgm.mit.edu (Wolfgang Rupprecht)
Newsgroups: comp.sys.m68k
Subject: Re: Virtual Machine (was: Apollo (was: MINIX port to A1000))
Message-ID: <1856@bloom-beacon.MIT.EDU>
Date: Sat, 21-Nov-87 12:44:38 EST
Article-I.D.: bloom-be.1856
Posted: Sat Nov 21 12:44:38 1987
Date-Received: Mon, 23-Nov-87 03:59:55 EST
References: <8711050534.AA25885@jade.berkeley.edu> <7862@ism780c.UUCP> <8965@utzoo.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wolfgang@mgm.mit.edu (Wolfgang Rupprecht)
Organization: Independent Software Consultant
Lines: 26
Keywords: virtual machine, emulation, 68010

>The generic solution to this is not to let the user's operating system
>meddle with the frames.  Keep the *real* frame somewhere private.  Give
>him a fake one, with the documented fields filled in from the real one,
>and the rest full of magic numbers and checksums and so on.  When he tries
>to do a return using the fake frame, check the checksums etc. [...]

There is still a real problem here. If the kernel keeps a copy of the
real frames, it will have to keep them *forever* (possibly even
across reboots), since a user might want to restart his faulted program
at any time. This puts the burden of storing a possibly infinite number
of bytes, on the kernel.

If one uses a checksum validation scheme, and passes a checksummed
frame to the user, once still has a security problem. Unless the
checksumming algorithm is secret, a user can just validate his own
phoney frame.

I'm of the opinion that 680x0 exception frames are a botch. They might
be a quick fix to instruction restart problem, but they are poorly
inplemented. If Motorola had only included a
validate_user-mode_exception-frame instruction we would be home free.
Let the 680x0 tell us if the frame is cool.
---
Wolfgang Rupprecht	UUCP: mit-eddie!mgm.mit.edu!wolfgang
				(or) mirror!mit-mgm!wolfgang
			ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114)