[EROS-Arch] Proposed new facility: reducing resume capabilities

[Jonathan S. Shapiro]

> Any of the keys invoked or passed in the jump could become [void] keys
which
> means that the second try would not be the same as the first.  Any user of
> this mechanism would be well advised to make no changes in state as a
> result of the first try.  This is classic "dry run" programming.
>
> Change the invoked key resulting in the information going to a different
> domain.
>
> Change the keys/data passed in the jump.

I agree with all of these statements. In the event that the transmitted keys
have been voided, the server already holds voided keys from the first
invocation; I see no security issue here.

In the event that the keeper changes the transmit keys, this is in some
sense a voluntary new transmission -- not a security issue, but definitely a
potential caution to server writers. I don't know that this is different
from a similar, completely new invocation that transmits different
arguments.

The only way the invoked key can be voided is if the server itself has been
rescinded. This seems unlikely, but might occur in the A calls B forwards to
C issues retry case.

In any case, all of these cases are triggered at the volition of the
service, because the service is ultimately in control of whether a requested
retry occurs. Further, all of these can already be induced using the keeper
tricks I mentioned previously.

> Since the PC has not advanced, the domain key holder sees the view that
the
> jump has not yet occurred, and should be suitably warned.

Mumble. Yes. I was trying (and failing) to remember why the decision of when
to advance the PC was important.

But this seems easily detected. If the instruction has been initiated then
the invoker is in the available or waiting state, not the running state. In
either case it can be assumed that it is in mid-invocation. Whether the PC
moves early or late you have the same problem; the only change is which
instruction we are asking the question about. Am I missing something?

It seems to me that the PC should either (a) always point to the instruction
being executed, or (b) always point to the next instruction to be executed.
As a CPU architect, my preference is (a), and this is why the EROS PC
advances when it does.


Jonathan