expand on the summary

Author: folkertdev

text/0000-cmse-calling-conventions.md

@@ -6,13 +6,20 @@
 # Summary
 [summary]: #summary
 
-Support the `cmse-nonsecure-entry` and `cmse-nonsecure-call` calling conventions on   `thumbv8` targets.
+Support for the `cmse-nonsecure-entry` and `cmse-nonsecure-call` calling conventions on   `thumbv8` targets, and a lint preventing (partially) uninitialized values from crossing the security boundary.
 
 # Motivation
 [motivation]: #motivation
 
 Rust and Trustzone form an excellent pairing for developing embedded projects that are secure and robust.
 
+Trustzone creates a security boundary between a secure and non-secure application. The secure application can work with secure information (e.g. encryption keys). By limiting the interactions between the secure and non-secure applications, large classes of security bugs are statically prevented.
+
+In embedded systems it is common to have an extra physical chip, a secure enclave, to handle secure information. With Trustzone, this additional chip is not needed: a secure enclave is created on the main chip instead.
+
+A specific use case is encapsulating C APIs. Providing a C interface is still the standard way for a hardware vendor to provide access to system components. Libraries for networking (LTE, Bluetooth) are notorious for their bugs. Running such code in non-secure mode significantly reduces the risk of bugs leaking secure information. 
+
+Trustzone is growing in availability and use. More and more of the new medium and large ARM microcontrollers have support. Large industry players have requested Rust support for Trustzone.
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
@@ -256,4 +263,26 @@ The [`cortex_m`](https://docs.rs/cortex-m/latest/cortex_m/cmse/index.html) crate
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
-Some ideas of future lints were discussed. For instance, an entry function that accepts a reference may set users up for failure.  The secure application (which defines the entry function) must consider the non-secure application to be hostile. Because the non-secure application can configure signal handlers that mutate arbitrary memory, there is a risk of time-of-check-time-of-use attacks. Assuming the strong guarantees of a reference might give a false sense of security.
+## Lint on references crossing the secure boundary 
+
+The secure application should never accept a reference because there is no guarantee that a hostile non-secure application does not provide an invalid value (`NULL`, not properly aligned, etc.). There are other types with layout assumptions (e.g. `NonZeroU64` and friends) that are almost certainly invalid for a secure application to accept.
+
+We'd like to wait with adding further lints until we see more usage of Trustzone, so that we can design a lint that covers all practical cases of too-strong assumptions.
+## An "initialize padding" attribute
+
+The current lint for partially uninitialized values crossing the security boundary does not have a proper workaround: the advice is to just not send such values over the secure boundary, and essentially treat the warning as an error.
+
+A suggestion that was floated is to provide some mechanism to ensure that a value is fully initialized, e.g. by zeroing any potentially uninitialized parts.
+
+One potential method is to extend the`repr` attribute with an option that adds fields where padding is needed internally. These user-hidden padding fields would be zeroed upon creation.
+```rust
+#[repr(C, align(8), initialized)]
+struct Foo { 
+	a: u8,
+	_padding0: [u8; 1],
+	b: u16,
+	_padding1: [u8; 4],
+}
+```
+
+This feature still has many open design questions. We don't think such an attribute is required for practical Trustzone development, so we defer it for now.