31
32000D–04/2011
AVR32
4.
Secure state
Revision 3 of the AVR32 architecture introduces a secure execution state. This state is intended
to allow execution of a proprietary secret code alongside code of unknown origin and intent on
the same processor. For example, a company with a proprietary algorithm can program this
algorithm into the secure memory sections of the device, and resell the device with the pro-
grammed algorithm to an end customer. The end customer will not be able to read or modify the
preprogrammed code in any way. Examples of such preprogrammed code can be multimedia
codecs, digital signal processing algorithms or telecom software stacks. Whereas previous
approaches to this problem required the proprietary code and the end user application to exe-
cute on separate devices, the secure state allows integration of the two codes on the same
device, saving cost and increasing performance since inter-IC communication is no longer
required.
In order to keep the proprietary code secret, this code will execute in a “secure world”. The end
user application will execute in a “nonsecure world”. Code in the nonsecure world can request
services from the secure world by executing a special instruction, sscall. This instruction is exe-
cuted in the context of an API specified by the provider of the proprietary code. The sscall
instruction can be associated with arguments passed in registers or memory, and after execu-
tion of the requested algorithm, the secure world returns results to the requesting nonsecure
application in registers or in memory.
Hardware is implemented to divide the memory resources into two sections, one secure and one
non-secure section. The secure section of the memories can only be accessed (read, written or
executed) from code running in the secure world. The nonsecure section of the memories can
be read, written or executed from the nonsecure world, and read or written from the secure
world.
The customer can choose if his application will enable the secure state support or not. An
IMPLEMENTATION DEFINED mechanism, usually a Flash fuse, is used to enable or disable
secure state support. If this mechanism is programmed so as to disable the secure state, the
system will boot in nonsecure world, and its behavior will be identical to previous devices imple-
menting older revisions of the AVR32 architecture. If the system is set up to enable secure state
support, the system will boot in the secure state. This allows configuration and startup of the
secure world application before execution is passed to the nonsecure world.
4.1
Mechanisms implementing the Secure State
The following architectural mechanisms are used to implement the secure state:
The sscall and retss instructions are used for passing between the secure and nonsecure
worlds.
The secure world has a dedicated stack pointer, SP_SEC, which is automatically banked into
the register file whenever executing in the secure world.
The SS bit is set in the status register whenever the system is in the secure state. Only sscall
and retss can alter this bit.
Interrupts and exceptions have special handler addresses used when receiving interrupts or
exceptions in the secure world. This allows executing the interrupt or exception handler in the
secure world, or jumping back into the nonsecure world to execute the handler there.
A set of secure system registers are used to configure the secure world behavior, and to aid
in communication between the secure and nonsecure worlds. These registers can be written
when in the secure world, but only read when in the nonsecure world.