Skip to content

Commit 966167e

Browse files
folkertdevdavidtwco
andcommitted
Apply suggestions from code review
Co-authored-by: David Wood <[email protected]>
1 parent 60c193a commit 966167e

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

text/0000-cmse-calling-conventions.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
# Summary
77
[summary]: #summary
88

9-
Support the `cmse-nonsecure-entry` and `cmse-nonsecure-call` calling conventions.
9+
Support the `cmse-nonsecure-entry` and `cmse-nonsecure-call` calling conventions on `thumbv8` targets.
1010

1111
# Motivation
1212
[motivation]: #motivation
@@ -16,7 +16,7 @@ Rust and Trustzone form an excellent pairing for developing embedded projects th
1616
# Guide-level explanation
1717
[guide-level-explanation]: #guide-level-explanation
1818

19-
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.
19+
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.
2020

2121
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.
2222

@@ -74,7 +74,7 @@ LL | pub extern "cmse-nonsecure-entry" fn f1(_: u32, _: u32, _: u32, _: u32, _:
7474
= note: functions with the `"cmse-nonsecure-entry"` ABI must pass all their arguments via the 4 32-bit available argument registers
7575
```
7676

77-
The error is generated during `hir_ty_lowering`, and therefore even a `cargo check` will emit these errors. Note that LLVM also checks the ABI properties, but it generates poor error messages late in the compilation process.
77+
The error is generated after type checking but before monomorphization, meaning that even a `cargo check` will emit these errors, and the errors are emitted even for unused functions. Note that LLVM will also check the ABI constraints, but it generates poor error messages late in the compilation process.
7878

7979
Because Rust is not C, we impose a couple additional restrictions, based on how these ABIs are (meant to be) used.
8080

@@ -93,12 +93,12 @@ LL | extern "cmse-nonsecure-entry" fn return_impl_trait(_: impl Copy) -> impl Co
9393
The `cmse-nonsecure-call` calling convention can only be used on function pointers, which already disallows generics. For `cmse-nonsecure-entry`, it is standard to add a `#[no_mangle]` or similar attribute, which also disallows generics. Explicitly disallowing generics enables the layout calculation that is required for good error messages for signatures that use too many registers.
9494
### No C-variadics (currently)
9595

96-
Currently both ABIs disallow the use of c-variadics. For `cmse-nonsecure-entry` the toolchain actually does not support c-variadic signatures (likely because of how they interact with veneers, though the specification does not say that explicitly).
96+
Currently both ABIs disallow the use of c-variadics. For `cmse-nonsecure-entry`, the toolchain actually does not support c-variadic signatures (likely because of how they interact with veneers, though the specification does not say that explicitly).
9797

9898
- clang rejects c-variadic entry functions: https://godbolt.org/z/MaPjzGcE1
9999
- but accepts c-variadic nonsecure calls: https://godbolt.org/z/5rdK58ar4
100100

101-
For `cmse-nonsecure-call` we may stabilize c-variadics at some point in the future.
101+
For `cmse-nonsecure-call`, we may stabilize c-variadics at some point in the future.
102102
### Warn on unions crossing the secure boundary
103103

104104
Unions can contain uninitialized memory, and this uninitialized memory can contain stale secure information. Clang warns when union values cross the security boundary (see https://godbolt.org/z/vq9xnrnEs), and rust does the same.

0 commit comments

Comments
 (0)