• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• [ Next ] In reply to: bill One

What follows is an explanation of how exception handling is done in EROS. There is a question raised about communication channels between keepers that I'ld appreciate reactions to from the KeyKOS crowd.

Bill (i.e. bill1)

The context of the segment keeper discussion is dealing with page access violations and invalid memory references. Segment keepers are not consulted for other faults. The relationship between the segment keeper and the process keeper is not hierarchical.

If there is an applicable segment keeper, and a memory fault occurs, the fault is delivered first to the segment keeper. The segment keeper can either

1. solve the problem and restart the process
2. ignore the problem and leave the process hung
3. do something gratuitously stupid like infinite loop or similar misbehavior
4. pass the buck to the process keeper to be solved
5. try and fail to solve the problem and pass the buck to the process keeper to be solved

We are concerned here with cases (4) and (5).

If the segment keeper does not wish to attempt a solution to the problem, it should pass to the keeper the same information as to "cause of fault" that it received.

In the current EROS design, the segment keeper is able to change the "fault code" of the process (think of this as the exception number). This may be a mistake, because it provides an avenue for the segment keeper to attempt to subvert the process keeper by passing valid but inaccurate fault codes to the process keeper. The process keeper can program defensively, but why should we force it to?

• Is there really an issue here in subverting via the fault code?
• Should the semantics of the EROS restart key be changed to resume/pass-the-buck with no change of fault code?

On the other hand, if the segment keeper tries to fix the problem and cannot for (e.g.) lack of memory, it is conceivably useful for the process keeper to be able to learn this. The process keeper may not be able to trust this result, but on the other hand it *may* be able to trust the result.

This can be accomplished by recording in a dedicated pseudo-register for the process the last order code passed to the fault key. This pseudo register's value can be delivered to the process keeper as part of the process register set.

The down-side to this mechanism is that a non-zero value can be used by the process keeper to distinguish segment-keeper originated fault messages and kernel originated fault messages.

• In practice, does anyone see a use for this given that the process keeper cannot reliably trust the segment keeper? There is a small communication channel here, because the process keeper receives a word from the segment keeper and can now reliably detect that the segment keeper was really the source.

It would be helpful to resolve this before the first EROS release, since changing the process keeper register structure after that point gets awkward.

shap

• [ Next ] In reply to: bill One