Access control to the SPI core

[dehanj]

Description

Access control to only allow the SPI to be operated from fw.

Fixes #234

Type of change

Please tick any that are relevant to this PR and remove any that aren't.

• Feature (non breaking change which adds functionality)

Submission checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my changes
• I have tested and verified my changes on target
• My changes are well written and CI is passing
• I have squashed my work to relevant commits and rebased on main for linear history
• I have added a "Co-authored-by: x" if several people contributed, either pair programming or by squashing commits from different authors.
• I have updated the documentation where relevant (readme, dev.tillitis.se etc.)
• QEMU is updated to reflect changes

[dehanj]

Superseeds #243

[dehanj]

I have now tried to verify the access control.

I'm using a custom firmware which has both the spi and flash lib from my earlier test program.
See branch spi_access_fw_2, and look in main.c:398. The spi_test() function can be called form an app.

I'm then using the app in the repo tkey-spi-master-test, branch test_access_2 which first calls the function in firmware and prints the output, and then tries to run the same function locally in the app - which seems to fail, and does not provide any output. I will look into the SPI-lines tomorrow to confirm.

The output from the call to fw yields: EF 13 DC 62 14 62 8B A6 32 38 EF 40 14, which seems to be correct.

All in all, it seems to work well. What have I missed?

[dehanj]

I have now tested additionally three scenarios:

1. Call and use the SPI directly from fw, without an app even being loaded.
2. Check that the the signals on the traces looks fine, using logic analyser (both from fw and from app using the trampoline to fw)
3. Check that it is not possible to send any data to the SPI API (SPI_DATA, SPI_XFER) from the app. Also checked that the SPI trampoline/SPI API works after one have tried to use the SPI API directly from the app.

All seems fine.

[dehanj]

Okay, I have a few questions.

I have tested the functionality and it seems sound from the current standpoint, I can access the SPI from FW, and from the trampoline in an app - otherwise I cannot access SPI.
However, I'm not sure this implementation with the current trampoline is what we want when it comes the syscalls we want to offer.

This is the description of the current logic

Access logic looks at instruction execution from a defined
trampoline address to enable stateful SPI access.

The access is disabled as soon as an instruction is executed
from any address in RAM

From this, it sounds like you only can reach the SPI core if you use the _SPI_CMD tampoline. Is that right?
But is then the access enabled at start up? Because I have no issue accessing the SPI from fw at startup, even if I don't use the function set to the _SPI_CMD trampoline.

From other discussions we want to offer a few syscalls, these will not be directly to the SPI core, but instead to some fw function performing some calculations, and then that fw function will call the SPI core. But that fw function might want to use other functions than what is set to the _SPI_CMD trampoline. Would that be possible?

All in all, this seems to work - the questions is if it fulfills the needs we have with persistent storage.
And I cannot fully decipher how the access control works..