PAL-Enforced CPU Usage Constraints

[JaredWright]

Summary

The goal of this discussion is to brainstorm if/how PAL could be used to encapsulate logical constraints surrounding the usage of CPU instruction and registers, and enforce them at runtime or compile time.

Background Context

CPU instructions and registers often have logical constraints (or documented suggestions) that relate to their usage in a given execution environment. For example, the Intel x86_64 architecture contains the SGX processor extension which comprises system registers (MSRs, CPUID leaves) and instructions (e.g. ENCLS). Intel's documentation for SGX (Volume 3, Chapter 37.7) describes considerations for how to properly enable SGX:

On processors that support Intel SGX, IA32_FEATURE_CONTROL provides the SGX_ENABLE field (bit 18). Before system software can configure and enable Intel SGX resources, BIOS is required to set IA32_FEATURE_CONTROL.SGX_ENABLE = 1 to opt-in to the use of Intel SGX by system software.
The semantics of setting SGX_ENABLE follows the rules of IA32_FEATURE_CONTROL.LOCK (bit 0). Software is considered to have opted into Intel SGX if and only if IA32_FEATURE_CONTROL.SGX_ENABLE and IA32_FEATURE_CONTROL.LOCK are set to 1.

The above presents two logical preconditions that must be satisfied before an SGX instruction can be executed:

1. IA32_FEATURE_CONTROL.SGX_ENABLE is set to the value 1
2. IA32_FEATURE_CONTROL.LOCK is set to the value 1

It might be interesting if PAL could enforce this constraint in some program (e.g. Rust code within a BIOS) like the following:

// The developer sets IA32_FEATURE_CONTROL.SGX_ENABLE
pal::msr::ia32_feature_control::enable_sgx_enable();

// Ooops! The developer forgets to set IA32_FEATURE_CONTROL.LOCK at some point later

// Then the developer tries to initialize an enclave using the encls instruction
pal::instruction::execute_encls(2); // <-- This line could trigger something useful like throwing/printing an error

What could this be used for?

• Catch programing mistakes related to usage of hardware during development of an OS, hypervisor, BIOS, etc.
• Express and enforce security policies and assumptions. For example, if you had a policy like "SGX isn't allowed to be enabled on this computing platform", then PAL could help enforce that rule.

Challenges

For something like this to happen, there are a few challenges to overcome:

1) Expressing CPU constraints and semantics

PAL would need something to express constraints in both a human-friendly and machine-friendly format. It would need to be complete enough to describe both logical and temporal relationships between components within a CPU. Perhaps a language like Gherkin would be feasible? For example, you could write a constraint like this:

Scenario:
    Given pal.cpuid.leaf_07_ebx.sgx is enabled
    When pal executes encls
    Then pal.msr.ia32_feature_control.sgx_enable must be enabled first
    And pal.msr.ia32_feature_control.lock must be enabled first

2) Add pre and post instruction callback points to PAL generated code

Code generators for PAL's language-specific APIs would need to be extended with a mechanism to register callback points before and after an instruction gets executed. For example, PAL would need to generate all of the functions in the following pseudo-Rust-code's main() routine:

fn my_pre_encls_callback() {
    // logic goes here to be executed before pal executes the encls instruction
}

fn main() {
    // PAL could let you register pre (or post) instruction callbacks:
    pal::instruction::register_pre_encls_callback(my_pre_encls_callback);

    // Then when you go to execute the instruction, PAL would execute the callback first (or after)
    pal::instruction::execute_encls(); 
}

3) A way to bridge (1) and (2) together

For example, could PAL (or something else?) look at constraints expressed in (1), and then generate a program (2) that sets up PAL to enforce those constraints?