OSDev.org

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:



or, to make the syntax a bit more obvious to humans:



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:



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:



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?

Why could you not just check these things at the beginning of the function? The cost of adding a mandatory header instruction to every function being called would be very high, and this sort of thing messes with modular programming.

What do you gain by adding this in hardware that would be worth it?

Well, this kind of instruction is not often used, usually you use the Stack.
But for special needs are Special registers;-)
Intel Provides some MSR's for that (http://download.intel.com/products/proc ... 325384.pdf Section 17)
and AMD provides these Kinds of MSR's, too.

Who needs assert() anyway...

This would not work well, because the middle of an instruction or a data item could accidentally encode such an instruction.

It would be better to have the ability to mark a page as containing nothing but call gates that could be invoked with a normal call instruction.

Ooh. I'd thought of the potential for CMFRM to show up in data, but not in the middle of instructions. Good point.

Just as a sidepoint, a "comefrom" instruction might actually be useful, and is commonly used in compilers (as a phi node): http://en.wikipedia.org/wiki/Static_sin ... nment_form