Interaction of Normal and Secure worlds
If you are writing code in a system that contains some Secure services, it can be useful to understand how these are used. A typical system has a light-weight kernel or Trusted Execution Enviroment (TEE), hosting services, for example, such as encryption in the Secure world. This interacts with a rich OS in the Normal world that can access the Secure services using the SMC call. In this way, the Normal world has access to service functions, without exposing the keys to risk.
Generally, application developers do not directly interact with
Security Extensions, TEEs, or Trusted Services. Instead, they use a high-level API such
authenticate(), provided by a Normal world library. The library is
provided by the same vendor as the Trusted Service, for example, a credit card company,
and handles the low-level interactions. The following figure shows this interaction in
the form of a flow from the user application calling the API that makes an appropriate
OS call, which passes to the driver code, and then passes execution into the TEE through
the Secure monitor.
It is often necessary for data to be passed between the Secure and Normal worlds.
For example, in the Secure world you might have a signature checker. The Normal world can request that the Secure world verifies the signature of a downloaded update, using the SMC call. The Secure world requires access to the memory used by the Normal world. The Secure world can use the NS-bit in its translation table descriptors to ensure that it uses Non-secure accesses to read the data.
This is important because data relating to the package might already be in the caches, because of the accesses that are executed by the Normal world with addresses marked as Non-secure. The security attribute can be thought of as an extra address bit. If the core uses Secure memory accesses to try to read the package, it will not hit on Non-secure data already in the cache.
If you are a Normal world programmer, in general, you can ignore what happens in the Secure world, as its operation is hidden from you. One side effect is that interrupt latency can increase slightly. The Secure world can be fully blocking so if an interrupt occurs to request Secure kernel execution this might block the Normal world interrupts, but this increase is small compared to the overall latency on a typical OS. Quality-of-service issues of this type depend on good design and implementation of the Secure world OS.