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

[Charles Landau]

"Jonathan S. Shapiro" wrote:

> > OC_GetRegs32 followed by OC_SetRegs32 provides a
> > machine-independent way to set the PC and SP. It
> > shouldn't be necessary to also allow it via
> > OC_Process_Swap(ProcPCandSP).
>
> I'm looking into the test discrepancy now, but I disagree with your comment
> above. OC_Get/SetRegs is machine dependent. While the call exists on all 32
> bit architectures, the structure returned is inherently architecture
> specific.

These methods accept and return the Registers structure defined at
http://www.eros-os.org/eros-src/sys/eros/i486/Registers.h#29. In that
structure, the pc and sp appear near the beginning, before the comment:
/* architecture-specific registers start here: */
implying that their locations are the same on all (32-bit) architectures. 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.

That is easier than using OC_Process_Swap. The slot in the process root
containing the pc and sp also contains architecture-specific stuff (on i486, CS
and SS, which is why my test got into trouble). So I would need to read the key
in that slot, read the data from that number key, construct a new number key
containing the desired pc and sp and the remaining architecture-specific data,
and then store that number key in the slot of the process root. And mind you,
constructing a number key requires a node.

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 is one reason why "swap space and PC" was introduced. Swap
> space and PC truly is machine independent across all 32 bit architectures.
>
> The other reason is that "swap space and PC" must be called by protospace,
> which runs in a purely read-only address space and therefore has no place to
> store the result of OC_GetRegs. Because of this, OC_GetRegs cannot be used
> there.
>
> Finally, note that OC_SetRegs does not provide a mechanism to simultaneously
> change the address space capability. The protospace logic requires a
> mechanism that revises both the address space and the PC as a single atomic
> operation.

"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.

If we make it easier to read and write the pc and sp as proposed above, then I
am still not sure that there is any good reason to allow
OC_Process_Copy/Swap(ProcPCandSP). It isn't a security bug in itself, assuming
that ValidateRegValues() works. (ValidateRegValues() is needed in case a slot
in a process root is written via a node key.) But I consider it a trap for the
unwary (namely me).

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.