sancus-tee / sancus-core

Minimal OpenMSP430 hardware extensions for isolation and attestation
BSD 3-Clause "New" or "Revised" License
20 stars 13 forks source link

Consider remapping Sancus opcodes #4

Open jovanbulck opened 7 years ago

jovanbulck commented 7 years ago

Currently, Sancus-specific opcodes are encoded as a single-operand MSP430 instruction from 0x1380 onwards. More specifically, the three higher bits of the instruction word ir[15:13] are set to 0 to indicate the single-operand instruction range, and the three lower bits ir[2:0] identify one of 8 existing Sancus instructions.

Limitations. MSP430 single-operand instructions normally use ir[6:0] to encode the operand addressing mode and register. As such, Sancus instructions currently expect arguments in fixed registers (from r15 onwards). In practice, this means moving arguments to and from r15, increasing code side, slowing down execution, and limiting flexibility for hand-written assembly programs.

Proposed Solution. Reserve ir[6:0] for MSP430 addressing mode and register, so frequent single-operand Sancus instructions such as sancus_get_id and sancus_get_caller_id can encode their operand as usual. Fall back to fixed registers for (relatively infrequent) Sancus crypto instructions that expect more than one operand. Alternatively, multi-operand Sancus instructions could expect a memory address of a struct containing all info.

Regarding MSP430 single-operand instruction encoding, bits ir[12:10] seem to be unused. We could therefore use these to encode the Sancus instruction type.