-
Notifications
You must be signed in to change notification settings - Fork 0
RFC for CMSE calling conventions #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
ec454f6 to
57aecf6
Compare
57aecf6 to
7ceff6b
Compare
ac34e96 to
5c4e542
Compare
5c4e542 to
9bc68b6
Compare
davidtwco
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely unfamiliar with cmse so might not notice some parts where it would be helpful to introduce things differently - but this covers everything I'd expect it to.
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| Rust and Trustzone form an excellent pairing for developing embedded projects that are secure and robust. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to elaborate on this - what do people build with these calling conventions that they can't today? why is that something we want to support? how common is it use these calling conventions? etc.
|
|
||
| The cmse calling conventions are part of the *Cortex-M Security Extension* that are available on thumbv8 systems. They are used together with Trustzone (hardware isolation) to create more secure embedded applications. Arm defines the toolchain requirements in [ARMv8-M Security Extensions: Requirements on Development Tools - Engineering Specification](https://developer.arm.com/documentation/ecm0359818/latest/), but of course this specification needs to be interpreted in a rust context. | ||
|
|
||
| The main idea of Trustzone is to split an embedded application into two executables. The secure executable has access to secrets (e.g. encryption keys), and must be careful not to leak those secrets. The non-secure executable cannot access these secrets or any memory that is marked as secure: the system will hardfault if it tries to dereference a pointer to memory that it does not have access to. In this way a whole class of security issues is simply impossible in the non-secure app. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd pull forward some of the content in the Background section so that this feature is fully understood before you go on to explain the details of using it in Rust.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been struggling with this a bit: currently the background is sparse, and I'm trying to call out just the details that are relevant for T-lang. Are there specific parts that you think deserve more attention here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I have a great suggestion either - I haven't had the best hit rate for anticipating the background that would be useful for features like these, perhaps ask someone on t-lang to give it a pre-read for you?
Co-authored-by: David Wood <[email protected]>
42b9a9e to
966167e
Compare
fe4a1d1 to
ddef450
Compare
Rendered