Security Configuration
General Security Configuration
Secure boot configuration is mainly used to configure BL1 and BL2 secure boot related information:
secureboot_en- Optional, indicates whether secure boot is enabled, disabled by default.
flash_aes_en- Optional, indicates whether FLASH AES encryption is enabled, disabled by default.
flash_aes_key- Optional, indicates the FLASH AES encryption key. Must be configured whenflash_aes_enis enabled.
root_key_type- Optional. Defaults to ec256. Configures the public key type for BL1/BL2 signing, options are ec256, rsa2048.
root_pubkey- Optional, must be configured for production versions. BL1/BL2 public key file.
root_privkey- Optional, must be configured for production versions. BL1/BL2 private key file. The build tool will use the private key to sign BL2.
debug_key_type- Optional. Defaults to ec256. Configures the public key type for secure debug signing, options are ec256, rsa2048.
debug_pubkey- Optional, must be configured for production versions. Secure debug public key file.
debug_privkey- Optional, must be configured for production versions. Secure debug private key file.
Note
To simplify configuration, BL1/BL2 use the same public key for signing.
Secure Peripheral Configuration
Secure peripherals are configured through ppc.csv and gpio_dev.csv.
ppc.csv
ppc.csv is used to configure peripheral security attributes. Configuration example is as follows:
Device |
Secure |
Privilege |
|---|---|---|
UART0 |
FALSE |
TRUE |
UART1 |
TRUE |
TRUE |
GPIO0 |
FALSE |
TRUE |
GPIO1 |
TRUE |
TRUE |
The configuration table has three fixed columns:
Device- Required. Indicates the device name. Device names are generally uppercase device abbreviations, such as UART1, etc.
Secure- Optional. Indicates whether the peripheral is a secure peripheral. Optional values are:
TRUE - Indicates whether the device belongs to secure peripherals.
FALSE - Secure peripherals can only be accessed in the secure world.
NA - Indicates the peripheral is not used.
Not configured - Same as NA.
Privilege- Optional, indicates whether the device belongs to privileged peripherals. Optional values are:
TRUE - Indicates the device is a privileged peripheral, can only be accessed in processor privileged state
FALSE - Indicates non-privileged peripheral.
NA - Indicates the peripheral is not used.
Not configured - Same as NA.
Note
If a configurable device is not in ppc.csv, it indicates the peripheral is not used.
gpio_dev.csv
gpio_dev.csv is used to configure peripheral and GPIO mapping relationships. Configuration example is as follows:
GPIO |
Device |
|---|---|
GPIO0 |
UART1 |
GPIO1 |
UART1 |
The configuration table has two fixed columns:
GPIO- Required. GPIOx indicates GPIO x.
Device- Required. Indicates which peripheral this GPIO is used by.
The purpose of gpio_dev.csv is to ensure consistency between peripheral security attributes and their associated GPIO attributes. The Armino build system will traverse the ppc.csv configuration table. For peripherals that will be used in the system, it will find all GPIOs from gpio_dev.csv. If these GPIO attributes do not match the peripheral security attributes, it will give a prompt and automatically correct the GPIO security attributes.
Taking UART1 in the above example, from gpio_dev.csv we know UART1 uses GPIO0/GPIO1, so UART1’s security attributes and GPIO0/1 must be consistent. From ppc.csv configuration, UART1 is configured as secure, GPIO0/1 are configured as non-secure/secure respectively. GPIO0’s security attributes differ from UART1, so the build system will automatically adjust GPIO0’s security attributes to secure.
Note
If a peripheral is not used in the system, then all GPIOs used by that peripheral will not be adjusted according to gpio_dev.csv.
Code Generation
For each row in ppc.csv, two macros are generated in security.h to identify device security attributes.
Device |
Secure |
Privilege |
|---|---|---|
uart0 |
FALSE |
FALSE |
Taking the above table’s uart0 configuration as an example, the following code is generated:
#define GEN_SECURITY_DEV_UART0_IS_SECURE 0
#define GEN_SECURITY_DEV_UART0_IS_PRIVILEGE 0
Additionally, four external interfaces are generated:
#define DEV_IS_PRIVILEGE(dev) GEN_SECURITY_DEV_##dev##_IS_PRIVILEGE
#define DEV_ID_IS_PRIVILEGE(dev, id) GEN_SECURITY_DEV_##dev##id##_IS_PRIVILEGE
#define DEV_IS_SECURE(dev) GEN_SECURITY_DEV_##dev##_IS_SECURE
#define DEV_ID_IS_SECURE(dev, id) GEN_SECURITY_DEV_##dev##id##_IS_SECURE
In Armino, peripheral security attributes can be accessed by calling the above four external interfaces.
Secure Block Peripheral Configuration
Block peripherals are configured through mpc.csv. Configuration example is as follows:
Device |
Offset |
Size |
Secure |
|---|---|---|---|
MEM0 |
16k |
TRUE |
|
MEM0 |
32k |
FALSE |
|
MEM0 |
16k |
TRUE |
|
MEM1 |
0x10000 |
64k |
TRUE |
FLASH_CODE |
0x20000 |
64k |
FALSE |
FLASH_DATA |
0x30000 |
64k |
TRUE |
The configuration table has four fixed columns:
Device- Required. Device name.
Offset- Optional. Device internal offset.
Not configured, if it’s the first configuration block for this device, Offset is 0, otherwise it indicates the end address of the previous block.
Offset + Size cannot exceed the device’s total storage size.
Offset cannot overlap with the previous block address on the same device.
Size- Required. Configuration block size. Must be aligned to device block size.
Secure- Optional. Configuration block security attribute, defaults to False when not configured.
For configurable devices, device storage space size, device block size, please refer to Block Memory Security Access.
Note
When a device block is not configured, it defaults to non-secure.
FLASH Security Attribute Configuration
In the mpc.csv configuration table, FLASH configuration is special because it includes instruction port and data port configuration. FLASH instruction port/data port configuration uses FLASH_CODE/FLASH_DATA to indicate device names respectively. Physical addresses are always used for configuration. For FLASH addresses, please refer to FLASH Security.
Important
When configuring FLASH instruction port, physical addresses must be 68K aligned, so that the converted virtual address is 64K aligned.