sancus-tee / sancus-core

Minimal OpenMSP430 hardware extensions for isolation and attestation

sancus-core

Minimal OpenMSP430 hardware extensions for isolation and attestation.

Overview

Please refer to the Sancus website for installation instructions.

sancus-core's Issues

sancus-sim: Loguru caught a signal: SIGSEGV

When installing fresh on Ubuntu 22.04, sancus-sim (Verilator) ends with a SEGV. This is relatively harmless, as it seems to only happen after the simulation has ended. Not sure where exactly it goes wrong? Maybe @fritzalder can have a look?

Might or might not have something to do with the warning I had to disable to get it to install on Ubuntu 22.04 with more recent verilator versions:

09adaef

Example output below (sancus-examples/hello-world):

jo@icecream:~/sancus-main/sancus-examples/hello-world$ verilator --version
Verilator 4.038 2020-07-11 rev v4.036-114-g0cd4a57ad
jo@icecream:~/sancus-main/sancus-examples/hello-world$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04 LTS
Release:	22.04
Codename:	jammy

jo@icecream:~/sancus-main/sancus-examples/hello-world$ make sim
sancus-cc -I"/usr/local/share/sancus-support"/include/ -Wfatal-errors -fcolor-diagnostics -Os -g   -c -o main.o main.c
sancus-ld -L"/usr/local/share/sancus-support"/lib/ --ram 16K --rom 41K  -lsm-io -ldev --inline-arithmetic --standalone --verbose -o no_wrap_main.elf main.o
INFO: Found new Sancus modules:
INFO:  * hello:
INFO:   - Entries: hello_disable, hello_greet
INFO:   - No calls to other modules
INFO:   - Unprotected calls: puts, printf2
INFO:   - YAML SM Configuration: No YAML config provided.
INFO: No existing Sancus modules found
INFO: No asm Sancus modules found
INFO: Found MSP430 install directory: /usr/msp430
INFO: Found MSP430 GCC install directory: /usr/lib/gcc/msp430/4.6.3
INFO: Using output file no_wrap_main.elf
INFO: Cleaning up temporary files: /tmp/tmpofole9o0.o, /tmp/tmp6o7_vl_y.o, /tmp/tmpy86_0unw.o, /tmp/tmp_fl1ee1d
sancus-crypto --fill-macs --key 4078d505d82099ba --verbose -o main.elf no_wrap_main.elf
sancus-sim --dumpfile=sancus_sim.vcd main.elf
2022-10-17 13:16:12.602 (   0.000s) [        246D33C0]               main.cpp:296   INFO| Using input file main.elf.
   v| 
INFO| arguments: sancus-sim --dumpfile=sancus_sim.vcd main.elf
INFO| Current dir: /home/jo/sancus-main/sancus-examples/hello-world
INFO| stderr verbosity: 0
INFO| -----------------------------------
INFO| ======================= Sancus Simulator =======================
INFO| { Performing objcopy of elf file
INFO| .   Generating temporary binary form of given elf file...
INFO| .   Temp file is /tmp/tmp_sancus_769JBI
INFO| .   >> msp430-objcopy -O binary main.elf /tmp/tmp_sancus_769JBI
INFO| .   ..done!
INFO| } 0.002 s: Performing objcopy of elf file
INFO| Using sancus_sim.vcd as simulation file.
INFO| Enabled automatic timeout after 1000000000 cycles.
INFO| Will abort simulation 0 cycles after any SM_VIOLATION
INFO| Read program memory of 41984 bytes.
=== SpongeWrap parameters ===
Rate:           16
Security:       64
Blocks in key:   4
=============================
=== Spongent parameters ===
Rate:        18
State size: 176
===========================

------


New SM 1 config: 6de8 70b4 0200 032c, 0
Vendor key: 4078d505d82099ba
SM key: fc30dc631ca41ab6
SM hello with ID 1 enabled	: 0x6de8 0x70b4 0x0200 0x032c
[main.c] Hi from SM with ID 1, called by 0
SM 1 disabled
[main.c] SM disabled; all done!


all done; exiting..



INFO| ======================== Simulation ended ========================
INFO| Total/crypto cycles simulated: 70229/34114.
INFO| ================ Simulation succeeded gracefully =================
INFO| atexit

Loguru caught a signal: SIGSEGV
FATL| Signal: SIGSEGV
make: *** [Makefile:21: sim] Segmentation fault (core dumped)

Support testbench in sancus-sim

Currently, the standard openMSP430 simulator code (core/bench/verilog/) and the Sancus simulator (core/sim/rtl_sim/sancus/) are duplicated. These should be merged again, so that sancus-sim can be ran with a Verilog stimulus file.

We could then run the standard openMSP430 testbench (core/sim/rtl_sim/src and core/sim/rtl_sim/src-c) to ensure backwards compatibility. Moreover, we could include our own custom tests for the custom Sancus instructions.

LED digits charlieplexer logic

Start` Verilog simulation...
../../../rtl/verilog/periph/omsp_led_digits.v:250: warning: @* is sensitive to all 8 words in array 'leds'.

Check for illegal NULL-pointer in crypto engine

Currently, sancus_wrap assumes some arguments (e.g., associated data) are valid non-NULL pointers. This can result in weird bugs from 0x0+offset memory writes.

While this is not a security issue, as trusted intra-SM code should never invoke sancus_wrap with incorrect arguments, and crypto memory accesses are subject to the usual memory protection checks, we could easily detect illegal arguments and fail with an error code return value.

Specify verbosity for sancus-sim

The simulator now $displays debug information on stdout for SM enable/disable/violation events. End user should be able to specify verbosity level via a custom command line argument. Additional verbose information may include: SM protection domain switches, violating instruction name, ...

Fix IRQ tests

In the last PR changes, we broke two of the CI tests:

 FAILED TESTS:
               -  ./log/sancus-sm_crypto_irq.log 
               -  ./log/sancus-sm_mem_violation.log 

Consider remapping Sancus opcodes

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.

Constant-time crypto state machine tag comparison

Documenting here a known issue (I spotted some time ago already): the hardware-level crypto state machine does not properly verify tags in constant time.

Depending on the application and usage, this could be dangerously exploited in a timing side channel to brute-force expected tags (eg used by sancus_verify) in linear time byte-per-byte.

Note this is not a problem when calling sancus_tag and then doing the provided tag comparison in constant-time software (eg as done in VulCAN).

Solution. Crypto state machine should always behave constant-time and only check the tag_ok signal after mem_done has finished:

https://github.com/sancus-tee/sancus-core/blob/master/core/rtl/verilog/crypto/crypto_control.v#L157

        VERIFY_TAG:        next_state = tag_ok      ? VERIFY_TAG_WAIT   : FAIL;
        VERIFY_TAG_WAIT:   next_state = mem_done    ? SUCCESS           :
                                        wrap_busy   ? VERIFY_TAG_WAIT   : VERIFY_TAG;

Make sure SM violation IRQ is served

SM violation IRQ (for debug purposes) doesn't always reliably fire. The signal should probably be buffered in the front-end for the remainder of the currently executing instruction.

Clear SM data section on sancus_enable

Currently, the data section doesn't seem to be cleared when enabling protection for an SM.

Add CPUID-like instruction

To facilitate portable Sancus application code, we should add a CPUID-like instruction that returns at least:

• Sancus version implemented by the processor (if any)
• Number of SMs supported by the processor
• Security level (key length) the cryptographic core was configured with

Enforce read-only SM code sections

Currently, the memory access logic in omsp_spm.v allows an SM to write to its own code section.

Crypto instructions assume pointers are 2-byte aligned

From @JobNoorman

This causes the output (cipher and tag) to be shifted by one byte if they are not aligned. This should either be fixed or just fail right away.

The length of the input should also be a multiple of two. If not, one byte is silently appended.

Crypto: `sancus_unwrap` always fails if `cipher_len` is zero

Ideally, what we would like to happen is a simple comparison between the provided MAC (tag) and the MAC calculated over the provided associated data (ad). This is not happening though, the return value of sancus_unwrap is always false.

Interestingly, sancus_wrap works fine if the plaintext length is zero. In fact, it returns true and the calculated MAC is correct.

Note that the result if the same no matter the value of the cipher pointer (NULL or not): if cipher_len is zero, sancus_unwrap always fails.

Clear caller ID on sancus_disable

Problem. The unprotect instruction currently does not clear caller ID, which may enable an attacker controlling the continuation argument to spoof one caller authentication in multithreaded programs, without interrupting SMs:

• thread 1: unprotected -> reader SM -> sensor SM (get data entry) -> unprotected (logging function)
• thread 2: unprotected -> sensor SM (disable entry) -> unprotected (continuation) -> reader SM

An attacker controlling the unprotected domain suspends thread1 on the unprotected sensor SM outcall. Next, the sensor SM is disabled in thread 2 and execution continues at an unprotected continuation point (with the valid callerID of the sensor SM). At this point, the attacker simply "returns" into the reader SM, passing arbitrary spoofed return values in CPU registers. The reader SM now cannot rely anymore on sancus_get_caller_id to authenticate this return call.

Solution. After execution of the unprotect instruction, the ID of the previously executing module should be zero.

implement sancus

I want to implement sancus, but I found that xula2-lx25 and StickIt! Board have stopped production, how can I get these two boards, thank you