sancus-tee / sancus-support Goto Github PK

If __ss_start() is called 9 times in a program, it causes a memory violation on the last run.

A minimal program to reproduce the issue:

#include <msp430.h>
#include <sancus/sm_support.h>
#include <sancus_support/sm_io.h>
#include <sancus_support/sancus_step.h>

DECLARE_SM(foo, 0x1234);

void SM_ENTRY(foo) dummy(void) {
    __asm__ __volatile__("nop\n\t":::);
}

void checkCounter(void)
{
    __asm__ __volatile__("nop\n\tnop\n\t":::);
}

int main()
{
    msp430_io_init();
    asm("eint\n\t");
    sancus_enable(&foo);

    for (int i = 0; i <= 11; ++i) {
        __ss_start();
        dummy();
    }

    EXIT();
}

/* ======== TIMER A ISR ======== */
SANCUS_STEP_ISR_ENTRY2(checkCounter, __ss_end)

Some observations I made:

• The instruction that causes the violation is MOV @r1+, r7 (pop r7) called from __unprotected_stub_dummy. The value of r1 at this point is 6f5c.

• At the end of the previous cycle, this same instruction is executed with r1 being 41F6. One cycle before, the value is again 41F6. (It seems like for every cycle but the last, this is consistent.)

• The instruction that restores the value of r1 prior to this instruction is in __unprotected_stub_dummy. For some reason, when this instruction executes in the 9th cycle, it does not restore the value that was previously stored in it. The value loaded in the last cycle is 6F60, this value never occurs in r1 before this point (as far as I can tell). Maybe this load gets corrupted by the IRQ? Or something overflows this memory location? I'm not sure why else this value would be loaded.

• I also tracked the value of the stack pointer in the protected module for each cycle. For each cycle, it looks like the following:

  Cycle	Start	End
  1	08c4	08c4
  2	08a8	08a8
  8	0800	0800
  9	07e4	07e4

I uploaded both the object dump and the waveform of the simulation here.

We should provide protected MMIO driver variants for some of the devices under src/dev (e.g., keypad). Driver logic should probably best be split up into a minimal asm MMIO SM and higher-level C functions that are to be included in the client protection domain.

Ideally, client SMs should be able to securely use protected I/O devices by including an <sm_support/sm_devname.h> header file, and providing some configuration variables at link time.