[top_darjeeling] Code execution support from SRAM not internal to OT subsystem
@neeraj-rv is already working on this.
Since Jan 18, 2023.
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
desc
If we need to support code execution from memories outside of the OT subsystem, there are a few things to consider:
- How is access to the external memory access controlled and how is OT involved in those controls?
- Do we need confidentiality, integrity and potentially freshness protection?
- If yes, this protection can either be implemented on the host side or the destination side.
Host side implies the OT subsystem verifies and decrypts instructions on the fly. This can be implemented using a simple mechanism or something more full blown like full memory encryption.
In the simple case, the minimum "block" size would need to be considered. We would then need to consider how the crypto blocks would be utilized in such a scheme and how to arbitrate these crypto blocks separately from generic software usage.
In the more full blown memory encryption case, we would need a full scheme that guarantees confidentiality, integrity and freshness.
Destination side implies something similar to what OT has done thus far, memory scrambling and integrity checking. This is much lighter overhead but would require host role IDs to be known such that keys can be switched on the fly.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.