[EROS-Arch] Setting PC (was: EROS security bug)

[Jonathan S. Shapiro]

> "swap space and PC", also known as OC_Process_SwapMemory32 (== 192), is clearly
> necessary and I have no complaint with it. I hope you are not confusing it with
> OC_Process_Swap(ProcPCandSP), which was the subject of my concern.
> OC_Process_Swap(k) == 64+k, and ProcPCandSP == 9.

I did confuse them temporarily, but then I figured out my error.

> [Re Get/Set regs]:
> ... It
> should be possible to read the Registers structure into a sufficiently large
> buffer (noting the length read), modify the pc and sp near the beginning, and
> write the structure for the same length, without knowing anything
> architecture-specific.

This makes me unhappy, because "sufficiently large" is insufficiently
correct. A better solution would be to provide a means to ask in advance
the size of the returned structure.  Another fine solution would be to
make the behavior well-defined if only the machine independent bytes are
fetched/stored.

I concur that using the get/set regs logic is easier than using
OC_Process_Swap, but this is ducking a question. Because a process root
could have an outstanding node capability, the KeyKOS design went out of
its way to preserve get/set slot operations on process root slots
wherever possible. This involves no marginal risk because the
possibility of a slot swap exists via the node cap anyway.

So I agree completely that use of OC_Process_Swap for this purpose
should be deprecated. In fact, I believe that no current programs use
it.  What I don't understand is why you are proposing that we should
remove the functionality.

> OC_SetRegs32 requires that the entire Registers structure be passed. I don't
> know why it can't just set as many registers as are passed. If this requirement
> were eliminated, it would be trivial to write the pc, or pc and sp....

This would work, but it's incompatible with the CapIDL interface
specification. We should introduce a new order code for this case if we
want to do this.

> In fact, I see no reason to require that all architectures store the pc and sp
> in a fixed slot of the process root (ProcPCandSP), but I suppose there's little
> harm in it.

The reason to do this is that it eliminates the need to build still more
machine dependencies into the mkimage program.

Jonathan