User:JSharp/OpenPOWER ISA Proposal 1

This is a work in progress and is presented here in rough draft form for feedback/comments. It still needs significant editing and revision.

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 completely destroy processor compliance with its nominal ISA.

The OpenPOWER ISA 3.0B provides for no way to detect cloaked reserved class instructions, prevent their execution by architected special purpose register, or specify that the processor continues to operate in a manor compliant with the OpenPOWER ISA after the execution of a reserved class instruction or indicate that it does not.

Given these restrictions and under-specifications, 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 possible 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; excluding the required execution of the system illegal instruction error handler.

• 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...)

Define three new processor modes: Strict (mandatory), Strict-Extended (optional), Extended (optional). Strict mode disables all non-architected operations, reserved instructions, etc. Strict-Extended permits all non-architected operations and semantics, but prohibits those non-architected operations and semantics from modifying the semantics of any architected operations or violating any architected processor behaviour. Extended mode drops any and all restrictions on non-architected operations and is equivalent to the existing treatment of reserved class instruction behaviour. The default operating mode for any ISA-compliant processor shall be strict mode. Mode transitions downward are to be treated as security model impacting.

Define a new system error handler for reserved class instructions, termed the system illegal reserved instruction error handler. By default, this error handler will invoke the system illegal instruction error handler. All reserved class instructions must invoke the system illegal reserved instruction error handler and are forbidden from invoking the system illegal instruction error handler except via the system illegal reserved instruction error handler. Once this has been implemented, if the system is not in Strict mode, then side-effects are permissible even if the system illegal reserved instruction error handler is invoked. Of course, if the system is in Strict-Extended mode, restrictions on modifying the semantics of architected operations are still in force. If the system is in Extended mode, everything is possible. Note that this may result in modified system operation which is no longer compliant with the ISA.