User:JSharp/OpenPOWER ISA Proposal 1

Underspecified Behaviour in OpenPOWER ISA 3.0B Permits Paradoxical ISA-compliant Arbitrary Violation of ISA Semantics

Undocumented instructions and experimental functionality implemented by OpenPOWER ISA-compliant processors provide a much needed opportunity for flexibility and experimentation in specialised processor designs while maintaining compatibility with existing software artifacts. However if such undocumented instructions are executable when the processor is being programmed only in accordance with the publicly available OpenPOWER ISA then it is possible that the integrity and guarantees of the OpenPOWER ISA may be violated. This is especially true of reserved class instructions (OpenPOWER ISA 3.0B Section 1.8.3) which are executable in lower privilege execution states (i.e. problem state).

Unfortunately, due to the way in which reserved class instruction behaviour is defined by OpenPOWER ISA 3.0B Section 1.8.3, it is possible that implemented reserved class instructions may change processor state and still cause the system illegal instruction handler to be executed. Such instructions, termed cloaked reserved class instructions, are undetectable.

At issue is the following passage, reproduced from the OpenPOWER ISA 3.0B section 1.8.3:

Any attempt to execute a reserved instruction will:
  * perform the actions described by the implementation if the instruction is implemented; or
  * cause the system illegal instruction error handler to be invoked if the instruction is not implemented

It appears that the authors of the OpenPOWER ISA 3.0B specification intended for the system illegal instruction error handler to be invoked if and only if the instruction were not implemented. However, the exact wording of the passage does not prohibit this behaviour, resulting in the loophole in question.

As the OpenPOWER ISA specifies fixed length instructions, techniques which rely on side-channels for detecting implemented/decodable instructions (such as sandsifter's usage of page fault semantics on x86) are not applicable to OpenPOWER ISA-compliant processors. Verification that a processor is compliant with its claimed ISA requires that any user be able to evaluate the behaviour by inspection and compare that behaviour to that of an ideal model of the processor as defined by the ISA specification. Further the auditor must trust that, through any architected operation available from within programs considered well-formed by the ISA specification, the processor's state remains at worst boundedly undefined and coherent with the ISA model. Unfortunately, if cloaked reserved class instructions are permitted then this guarantee can no longer be considered met as reserved class instruction behaviour is entirely undefined even if that behaviour is defined in such as way as to compeltely destroy processor compliance with its ISA.

The OpenPOWER ISA 3.0B provides for no way to detect cloaked reserved class instructions, prevent their execution by architected model specific register, or ensure that the processor is operating in a manor compliant with the OpenPOWER ISA after the execution of a reserved class instruction.

Given this, it is impossible to independently guarantee the compliance of a processor with the OpenPOWER specification post-execution of any cloaked reserved-class instruction. Additionally it is impossible to determine if any such instructions exist in any given implementation. As there is often no means to prevent the execution of any and all reserved instructions, it becomes effectively impossible to guarantee that processors will continue to operate in compliance with the OpenPOWER ISA during operation. It is also insufficient to provide for contractual breach remedy should a processor contain functionality which would otherwise render it in violation of the OpenPOWER specification, should the compliance be a specific requirement of the contract, because the behaviour of all reserved class instructions is explicitly completely undefined.

Obviously the purpose of an ISA is to provide a behavioural model for which users of processors bearing the badge of compliance can rely upon. The above under-specification undermines the very purpose of the OpenPOWER ISA and so must be addressed. Therefore the following actions are suggested:

Define the equivalent of an OpenPOWER ISA 3.0C with the following modifications:

In an equivalent of section 1.8.3, defining the behaviour of Reserved Class Instructions, require that any implementation of a reserved class instruction either invokes the system illegal instruction or has any effect, but never both. One possibly rendering of this requirement could be:

Any attempt to execute a reserved instruction will:

    * if the instruction is implemented
      * perform the actions described by the implementation; and
      * never cause the system illegal instruction error handler to be invoked

    * if the instruction is not implemented
      * cause the system illegal instruction error handler to be invoked; and
      * have no other effect

Whether or not an instruction is said to have been implemented shall be defined as whether
or not the instruction would have any effect on processor state, visible or invisible within
the ISA, should it be executed.

In the next major revision of the OpenPOWER ISA:

TODO (Standard mechanism for enumerating/enabling extended processor behaviour (i.e. strict by default, extended on demand), etc...)