At times, a "comefrom" (or CMFRM) instruction has been jokingly suggested for inclusion in a computer instruction set (for example, in this list:
http://homepage.ntlworld.com/brook.stre ... /pdp11.htm).
But it seems to me that a CMFRM instruction could actually be useful as a protection mechanism: Instead of the jokingly suggested format:
one could have:
constraints would be a field specifying certain constraints on processor state that must be met on executing the CMFRM instruction, with an exception being generated if the constraints weren't met.
On making certain types of control transfers (for example, far jumps and calls on an x86-like machine, or on all control transfers, if desired) the processor would check to see if the instruction at the destination address was a CMFRM, and would generate an exception if it weren't, or if processor state didn't match the constraints.
Depending on the constraints implemented in the processor in question, we might see:
A control transfer to this CMFRM instruction will only succeed if the address of the control transfer instruction is between
addr1 and
addr2. Might be useful for ensuring that a function is only called by other functions in the same module.
Similar to the above, a control transfer to this instruction will only succeed if the distance between the control transfer instruction and the CMFRM instruction is less than
offset.
Once again similar to the above (but allowing more room in the constraints field for other constraints, as it only takes one bit), a control transfer to this instruction will only succeed if the distance between the control transfer instruction and the CMFRM instruction is within a preset offset.
A control transfer to this instruction will only succeed if the processor is at a privilege level between
minpriv and
maxpriv (inclusive). This could be further extended by adding constraints on the privilege level coming out of the CMFRM instruction. For example:
Code: Select all
CMFRM minprivin, maxprivin, minprivout, maxprivout
or, to make the syntax a bit more obvious to humans:
Code: Select all
CMFRM minprivin, maxprivin TO minprivout, maxprivout
Would allow execution to proceed if the privilege level preceding the control transfer was between
minprivin and
maxprivin, but would make sure that the privilege level was between
minprivout and
maxprivout before continuing (by raising the current privilege level to
minprivout or lowering it to
maxprivout as needed).
If Intel had implemented a CMFRM instruction with the above four privilege constraints in designing x86 protected mode, call gates and the conforming/nonconforming code segment distinction would not have been necessary. Something like a call gate allowing a call from any privilege level to a function in a nonconforming DPL 0 code segment could be done as follows:
Code: Select all
CMFRM priv3, priv0 TO priv0, priv0
Something like a conforming code segment with a DPL of 2 (except applying to just one entry point instead of a whole segment) could be implemented like this:
Code: Select all
CMFRM priv3, priv2 TO priv3, priv2
And something like a non-conforming code segment with a DPL of 1 and no call gate could be implemented by having all four fields specify privilege level 1.
Thoughts?