Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.arch
Subject: resuming after fault (was GC & limit checking by MMU hardware)
Keywords: GC, stack, heap, MMU
Message-ID: <25899@mimsy.umd.edu>
Date: 5 Aug 90 21:27:40 GMT
References: <1990Jul19.151524.22544@diku.dk> <11075@alice.UUCP> <3729@auspex.auspex.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 50

In article <3729@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
(in re resuming a faulted instruction on the 680[123]0)
>Part of the problem is that Motorola:
>1) wouldn't commit to the the "stack puke" stored by the 680[1andup]0
>   being "safe" to hand to user-mode code; i.e., they wouldn't say
>   "nothing you can do to the 'stack puke' is risky";
>2) wouldn't describe the format of the "stack puke" to the extent
>   necessary to have the kernel validate it.

(the Sun-2 versus the VAX:)
>The former has more context than the latter; the former has the 68010
>"stack puke", the latter has, as I remember, just the First Part Done
>bit (and some of the general-purpose registers, for some of the
>long-running instructions like MOVCn).
>
>The latter is safe and, I think, appears in the "signal context"
>saved by a BSD signal, so that the instruction can be continued from
>user mode without the kernel having to tuck away one or more sets of
>context.

Right (except that the registers do not appear in the sigcontext;
the FPD bit is simply one in the PSL, and the VAX PSL is easy for
the kernel to verify).  (The registers are saved as part of the
trap handling sequence, and ultimately restored in the `sigreturn'
syscall called from the signal trampoline code in the u. area.)

Basically, the problem here is that on an exception, the 680[123]0
simply pushes the entire microengine state; a return from exception
reloads the microengine state so that the instruction can be continued
(rather than restarted, as on the VAX; the VAX `first part done' bit
allows restarting without resetting important context, e.g., the
registers for the character string instructions).

If there is no documented way to verify the state (as there is on the
VAX), it becomes difficult for an O/S to allow user code to handle an
exception: if the user code modifies the state, this could crash the
machine, or allow improper privileges.  The kernel can stash a copy of
the exception state (the `stack puke') and compare this on return to
ensure that it has not been changed, but this then limits the actions
user code can take.  If the user code elects not to return from the
signal (e.g., to longjmp instead), the kernel may wind up carrying
around useless copies of this state.

In terms of computer architecture, the lesson here is that there must
be a documented method to verify any state left behind.  *Someone* will
want it.  The simplest solution is not to leave state behind.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris
	(New campus phone system, active sometime soon: +1 301 405 2750)