- 11 Feb, 2017 1 commit
-
-
Masahiro Yamada authored
In the current code, both key_load() and key_create() call key_new() to allocate a key container (and they do not free it even if they fail). If a specific key is not given by the command option, key_load() fails, then key_create() is called. At this point, the key container that has been allocated in key_load() is still alive, and it is overwritten by a new key container created by key_create(). Move the key_new() call to the main() function to make sure it is called just once for each descriptor. While we are here, let's fix one more bug; the error handling code ERROR("Malloc error while loading '%s'\n", keys[i].fn); is wrong because keys[i].fn is NULL pointer unless a specific key is given by the command option. This code could be run in either case. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 05 Jul, 2016 1 commit
-
-
Yatharth Kochar authored
With the introduction of commit `96103d5a`, the Certificate Generation tool is not able to generate FWU certificate and while doing so it does segmentation fault. This happens because it is now required to pass non-volatile counter values to the `cert_create` tool from the command line for creating the trusted firmware certificates. But in case of creating FWU certificate these counter values are not being passed to the tool and as a consequence the `cert_create` tool try to use the NULL argument and errors out with Segmentation fault. This patch fixes this issue by providing a check before using the command line argument passed in the case of `EXT_TYPE_NVCOUNTER` certificate extension. Change-Id: Ie17d0c1502b52aaa8500f3659c2da2448ab0347a
-
- 30 Mar, 2016 1 commit
-
-
Juan Castillo authored
This patch adds non-volatile counter support to the Certificate Generation tool. The TBBR Chain of Trust definition in the tool has been extended to include the counters as certificate extensions. The counter values can be specified in the command line. The following default counter values are specified in the build system: * Trusted FW Non-Volatile counter = 0 * Non-Trusted FW Non-Volatile counter = 0 These values can be overridden by the platform at build time. Change-Id: I7ea10ee78d72748d181df4ee78a7169b3ef2720c
-
- 07 Jan, 2016 1 commit
-
-
Juan Castillo authored
The help message printed by the cert_create tool using the command line option -h (or --help) does not correctly list all the available command line options. This patch reworks the print_help() function to print the help messages in a data driven approach. For each command line option registered, an optional help message can be specified, which will be printed by print_help(). Help messages for the TBBR options (certificates, keys and images) are also provided. Fix a small bug in the short options string passed to getopt_long: the ':' was missing in the '-a' option (this option must take an argument). Fixes ARM-software/tf-issues#337 Change-Id: I9d08c2dfd349022808fcc884724f677eefdc1452
-
- 14 Dec, 2015 2 commits
-
-
Juan Castillo authored
This patch replaces all references to the SCP Firmware (BL0, BL30, BL3-0, bl30) with the image terminology detailed in the TF wiki (https://github.com/ARM-software/arm-trusted-firmware/wiki): BL0 --> SCP_BL1 BL30, BL3-0 --> SCP_BL2 bl30 --> scp_bl2 This change affects code, documentation, build system, tools and platform ports that load SCP firmware. ARM plaforms have been updated to the new porting API. IMPORTANT: build option to specify the SCP FW image has changed: BL30 --> SCP_BL2 IMPORTANT: This patch breaks compatibility for platforms that use BL2 to load SCP firmware. Affected platforms must be updated as follows: BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID BL30_BASE --> SCP_BL2_BASE bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo() bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2() Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
-
Juan Castillo authored
This patch applies the TBBR naming convention to the certificates and the corresponding extensions defined by the CoT: * Certificate UUID names * Certificate identifier names * OID names Changes apply to: * Generic code (variables and defines) * The default certificate identifiers provided in the generic code * Build system * ARM platforms port * cert_create tool internal definitions * fip_create and cert_create tools command line options * Documentation IMPORTANT: this change breaks the compatibility with platforms that use TBBR. The platform will need to adapt the identifiers and OIDs to the TBBR naming convention introduced by this patch: Certificate UUIDs: UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT Certificate identifiers: BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID OIDs: TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID BL30_HASH_OID --> SCP_FW_HASH_OID BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID BL31_HASH_OID --> SOC_AP_FW_HASH_OID BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID NS_BL2U_HASH_OID --> FWU_HASH_OID Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
-
- 09 Dec, 2015 1 commit
-
-
Yatharth Kochar authored
Firmware Update requires an X509v3 certificate which contains hashes for SCP_BL2U, BL2U and NS_BL2U images as extensions. This patch extends the Chain of Trust definition in the 'cert_create' tool to include the Firmware Update certificate and the required extensions (including command line options). A new field in the extension structure will be used to indicate that the extension is optional. In the case of an image hash extension, this field will tell the tool that the hash should be included in the certificate, but filled with zeros. Change-Id: I1f77a66b018826b71745910771f38d9cf6050388
-
- 23 Oct, 2015 2 commits
-
-
Juan Castillo authored
This patch introduces a new API that allows to specify command line options in the Chain of Trust description. These command line options may be used to specify parameters related to the CoT (i.e. keys or certificates), instead of keeping a hardcoded list of options in main.c. Change-Id: I282b0b01cb9add557b26bddc238a28253ce05e44
-
Juan Castillo authored
The certificate generation tool currently checks if all command line options required to create all certificates in the CoT have been specified. This prevents using the tool to create individual certificates when the whole CoT is not required. This patch improves the checking function so only those options required by the certificates specified in the command line are verified. Change-Id: I2c426a8e2e2dec85b15f2d98fd4ba949c1aed385
-
- 16 Jul, 2015 1 commit
-
-
Juan Castillo authored
This patch reworks the certificate generation tool to follow a data driven approach. The user may specify at build time the certificates, keys and extensions defined in the CoT, register them using the appropiate macros and the tool will take care of creating the certificates corresponding to the CoT specified. Change-Id: I29950b39343c3e1b71718fce0e77dcf2a9a0be2f
-
- 01 Jul, 2015 1 commit
-
-
Juan Castillo authored
Some Linux distributions include an OpenSSL library which has been built without ECDSA support. Trying to build the certificate generation tool on those distributions will result in a build error. This patch fixes that issue by including ECDSA support only if OpenSSL has been built with ECDSA. In that case, the OpenSSL configuration file does not define the OPENSSL_NO_EC macro. The tool will build successfully, although the resulting binary will not support ECDSA keys. Change-Id: I4627d1abd19eef7ad3251997d8218599187eb902
-
- 25 Jun, 2015 2 commits
-
-
Juan Castillo authored
This patch extends the 'cert_create' tool to support ECDSA keys to sign the certificates. The '--key-alg' command line option can be used to specify the key algorithm when invoking the tool. Available options are: * 'rsa': create RSA-2048 keys (default option) * 'ecdsa': create ECDSA-SECP256R1 keys The TF Makefile has been updated to allow the platform to specify the key algorithm by declaring the 'KEY_ALG' variable in the platform makefile. The behaviour regarding key management has changed. After applying this patch, the tool will try first to open the keys from disk. If one key does not exist or no key is specified, and the command line option to create keys has been specified, new keys will be created. Otherwise an error will be generated and the tool will exit. This way, the user may specify certain keys while the tool will create the remaining ones. This feature is useful for testing purposes and CI infrastructures. The OpenSSL directory may be specified using the build option 'OPENSSL_DIR' when building the certificate generation tool. Default is '/usr'. Change-Id: I98bcc2bfab28dd7179f17f1177ea7a65698df4e7
-
Juan Castillo authored
The cert_create tool calculates the hash of each BL image and includes it as an ASN.1 OCTET STRING in the corresponding certificate extension. Without additional information, the firmware running on the platform has to know in advance the algorithm used to generate the hash. This patch modifies the cert_create tool so the certificate extensions that include an image hash are generated according to the following ASN.1 structure: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, digest OCTET STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } The PolarSSL module has been updated to extract the image hash from the certificate extension according to this structure. Change-Id: I6d83430f12a8a0eea8447bec7c936e903f644c85
-
- 28 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch adds a tool that generates all the necessary elements to establish the chain of trust (CoT) between the images. The tool reads the binary images and signing keys and outputs the corresponding certificates that will be used by the target at run time to verify the authenticity of the images. Note: the platform port must provide the file platform_oid.h. This file will define the OIDs of the x509 extensions that will be added to the certificates in order to establish the CoT. Change-Id: I2734d6808b964a2107ab3a4805110698066a04be
-