sancus-tee / sancus-examples Goto Github PK

The sensor module SM_s should read data directly from an MMIO peripheral device, as discussed in the paper. The peripheral should probably be simulated in sancus-sim (e.g., use an existing peripheral such as the time stamp counter).

Should be done after compiler support for MMIO SMs has been merged.

Add a minimalistic example of how to dynamically load and attest an SM at runtime, using the untrusted sancus-support host software (ELF loader).

We probably want to modify sancus-main for this purpose.

Also, the Travis CI build should be triggered for every commit to any depending sancus repo (i.e., when changing compiler/core).

times out in CI and locally

We now hard code the sancus-examples test directories:

      matrix:
        example: [hello-world, sensor-reader, arithmetic, fileio, timer, violation, sancus-step, dma, dynamic-loader]

This can better be auto-generated using an ls in a first stage that is passed with a needs.output construct

https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/

Also, when merging this code, I think it'd make a lot of sense to have a minimalist (non-contiki) program with SM_INPUT/OUTPUT as part of the sancus-examples continuous integration to make sure everything keeps working?

Do you think such a mini example would be feasible?

https://github.com/sancus-tee/sancus-examples

yes it definitely makes sense, I'll keep this in mind!

Originally posted by @gianlu33 in sancus-tee/sancus-compiler#36 (comment)

Complete minimal working example of how to confidentially load, run, and unload an SM.

As discussed with @fritzalder we should simplify hello-world and hello-library to be more minimal and without confidential loading (which is also not supported on Aion).

Current hello-world can be renamed to something like hello-conf or so

Fritz:

I'd vote for renaming hello-world to confidential-sm and rewrite hellow-world to be simpler and use sancus enable only