fault handling (EROS/KeyKOS divergence)

[Jonathan S. Shapiro]

Norm and I also talked about the segment/process keeper question.

In KeyKOS, the kernel contrived to restrict the fault code value in
some funny ways, one of which is that the high bit was guaranteed to
be set if the segment keeper had modified the fault code.

This resolved the "spoofing" problem, but it leaves the following
problem:

	+ On some processors, for some faults, the PC points to the
	  instruction following the fault.

	+ It is therefore important that the domain keeper receive the 
	  correct fault code as generated by the kernel.

	+ In the KeyKOS design, the segment keeper can modify the
	  fault code.

I am now proposing a different mechanism, which is a small
modification of the current process fault state.

At present, an EROS process has

	A fault code (32 bits, but could be smaller)
	A fault info value (32 or 64 bits, according to architecture).

Both are passed to the process keeper as part of the fixed-point
register set.

I propose to add a new native-register-sized value (call it fault aux)
recording the last order code that was passed to a fault key for this
process.  This value will also be passed as part of the fixed-point
register set.

The fault aux value is zeroed by the kernel whenever a fault code is
set.  If a fault key is invoked with a zero SR0 value (send data
register zero, which is the order/return code in EROS), then the fault
aux status register is zeroed.  If a fault key is invoked with a
non-zero SR0 (send data register 0, which is the order/return code)
value, then the value of SR1 (the first register-based data argument)
is recorded in this new status word.

This allows the segment keeper to optionally pass information to the
domain keeper indicating the reason for non-repair.  The process
keeper may not be able to trust the segment keeper, in which case it
should ignore this value.


shap