- 05 Jun, 2017 2 commits
-
-
Soby Mathew authored
This patch adds support for RSASSA-PSS Signature Algorithm for X509 certificates in mbedtls crypto driver. Now the driver supports RSA PKCS2_1 standard as mandated by TBBR. NOTE: With this patch, the PKCS1_5 standard compliant RSA signature is deprecated. Change-Id: I9cf6d073370b710cc36a7b374a55ec96c0496461 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
The mbedTLS library requires larger heap memory for verification of RSASSA-PSS signature in certificates during Trusted Board Boot. This patch increases the heap memory for the same. Change-Id: I3c3123d7142b7b7b01463516ec436734895da159 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 31 May, 2017 1 commit
-
-
Antonio Nino Diaz authored
mbed TLS provides the debug API `mbedtls_memory_buffer_alloc_status()` to analyse the RAM usage of the library. When RSA is selected as algorithm, the maximum heap usage in FVP and Juno has been determined empirically to be approximately 5.5 KiB. However, The default heap size used when RSA is selected is 8 KiB. This patch reduces the buffer from 8 KiB to 6 KiB so that the BSS sections of both BL1 and BL2 are 2 KiB smaller when the firmware is compiled with TBB support. Change-Id: I43878a4e7af50c97be9c8d027c728c8483f24fbf Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 24 May, 2017 1 commit
-
-
Antonio Nino Diaz authored
The Trusted Firmware uses a subset of the APIs provided by mbed TLS. This subset internally uses `snprintf`, but the only format specifier used is '%d', which is supported by `tf_snprintf`. This patch makes mbed TLS use `tf_snprintf` instead of `snprintf`, saving 3 KB in both debug and release builds when TBBR is enabled. Change-Id: I7f992a21015930d7c0f4660e7a28ceefd60b9597 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 May, 2017 1 commit
-
-
Masahiro Yamada authored
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide any value (at least technically). For easier use of TBBR, this commit allows platforms to reuse the OIDs obtained by ARM Ltd. This will be useful for non-ARM vendors that do not need their own extension fields in their certificate files. The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the backward compatibility. For clarification, I inserted a blank line between headers from the include/ directory (#include <...>) and ones from a local directory (#include "..." ). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 12 May, 2017 2 commits
-
-
David Cunado authored
This patch renames MBEDTLS_KEY_ALG to TF_MBEDTLS_KEY_ALG. This completes the migration of TF specific macros so that they do not have the MBEDTLS_ suffix (see arm-trusted-firmware#874). Change-Id: Iad7632477e220b0af987c4db3cf52229fb127d00 Signed-off-by: David Cunado <david.cunado@arm.com>
-
David Cunado authored
An earlier patch (arm-trusted-firmware#874) migrated MBEDTLS_ suffixed macros to have a TBBR_ suffix to avoid any potential clash with future mbedtls macros. But on reflection the TBBR_ suffix could be confusing as the macros are used to drive TF-specific configuration of mbedtls. As such this patch migrates these macros from TBBR_suffix to TF_MBEDTLS_ suffix which more accurately conveys their use. Change-Id: Ic87642b653ceeaa03d62f724976abd5e12e867d4 Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 22 Mar, 2017 1 commit
-
-
dp-arm authored
These macros are not part of mbed TLS so they should not be prefixed with `MBEDTLS_` to avoid potential collision in the future. Use the `TBBR_` suffix to highlight that they only used in TF. `MBEDTLS_KEY_ALG` was not modified because that is documented and used by platforms to select the key algorithm. Change-Id: Ief224681715c481691c80810501830ce16e210b0 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 16 Feb, 2017 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit b621fb50 . Because of the Trusted Firmware design, timing-safe functions are not needed. Using them may be misleading as it could be interpreted as being a protection against private data leakage, which isn't the case here. For each image, the SHA-256 hash is calculated. Some padding is appended and the result is encrypted with a private key using RSA-2048. This is the signature of the image. The public key is stored along with BL1 in read-only memory and the encrypted hash is stored in the FIP. When authenticating an image, the TF decrypts the hash stored in the FIP and recalculates the hash of the image. If they don't match, the boot sequence won't continue. A constant-time comparison does not provide additional security as all the data involved in this process is already known to any attacker. There is no private data that can leaked through a timing attack when authenticating an image. `timingsafe_bcmp()` is kept in the codebase because it could be useful in the future. Change-Id: I44bdcd58faa586a050cc89447e38c142508c9888 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 06 Feb, 2017 1 commit
-
-
Douglas Raillard authored
Replace all use of memset by zeromem when zeroing moderately-sized structure by applying the following transformation: memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x)) As the Trusted Firmware is compiled with -ffreestanding, it forbids the compiler from using __builtin_memset and forces it to generate calls to the slow memset implementation. Zeromem is a near drop in replacement for this use case, with a more efficient implementation on both AArch32 and AArch64. Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 24 Jan, 2017 1 commit
-
-
Antonio Nino Diaz authored
To avoid timing side-channel attacks, it is needed to use a constant time memory comparison function when comparing hashes. The affected code only cheks for equality so it isn't needed to use any variant of memcmp(), bcmp() is enough. Also, timingsafe_bcmp() is as fast as memcmp() when the two compared regions are equal, so this change incurrs no performance hit in said case. In case they are unequal, the boot sequence wouldn't continue as normal, so performance is not an issue. Change-Id: I1c7c70ddfa4438e6031c8814411fef79fd3bb4df Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 19 Jan, 2017 1 commit
-
-
Antonio Nino Diaz authored
In mbedtls_x509_parser.c there are some static arrays that are filled during the integrity check and then read whenever an authentication parameter is requested. However, they aren't cleared in case of an integrity check failure, which can be problematic from a security point of view. This patch clears these arrays in the case of failure. Change-Id: I9d48f5bc71fa13e5a75d6c45b5e34796ef13aaa2 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 06 Jan, 2017 1 commit
-
-
Masahiro Yamada authored
This comment block says the default algorithm is ESDSA, while the code obviously sets the default to RSA: ifeq (${MBEDTLS_KEY_ALG},) MBEDTLS_KEY_ALG := rsa endif The git log of commit 7d37aa17 ("TBB: add mbedTLS authentication related libraries") states available options are: * 'rsa' (for RSA-2048) (default option) * 'ecdsa' (for ECDSA-SECP256R1) So, my best guess is the comment block is wrong. The mismatch between the code and the comment is confusing. Fix it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 15 Dec, 2016 1 commit
-
-
dp-arm authored
The previous code required that a certificate be signed with the ROT key before the platform's NV counter could be updated with the value in the certificate. This implies that the Non-Trusted NV counter was not being updated for Non-Trusted content certificates, as they cannot be signed with the ROT key in the TBBR CoT scheme. The code is reworked to only allow updating the platform's Trusted NV counter when a certificate protected by the Trusted NV counter is signed with the ROT key. Content certificates protected by the Non-Trusted NV counter are allowed to update the platform's Non-Trusted NV counter, assuming that the certificate value is higher than the platform's value. A new optional platform API has been introduced, named plat_set_nv_ctr2(). Platforms may choose to implement it and perform additional checks based on the authentication image descriptor before modifying the NV counters. A default weak implementation is available that just calls into plat_set_nv_ctr(). Fixes ARM-software/tf-issues#426 Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 03 Jun, 2016 1 commit
-
-
Soby Mathew authored
A production ROM with TBB enabled must have the ability to boot test software before a real ROTPK is deployed (e.g. manufacturing mode). Previously the function plat_get_rotpk_info() must return a valid ROTPK for TBB to succeed. This patch adds an additional bit `ROTPK_NOT_DEPLOYED` in the output `flags` parameter from plat_get_rotpk_info(). If this bit is set, then the ROTPK in certificate is used without verifying against the platform value. Fixes ARM-software/tf-issues#381 Change-Id: Icbbffab6bff8ed76b72431ee21337f550d8fdbbb
-
- 31 Mar, 2016 1 commit
-
-
Juan Castillo authored
This patch adds support for non-volatile counter authentication to the Authentication Module. This method consists of matching the counter values provided in the certificates with the ones stored in the platform. If the value from the certificate is lower than the platform, the boot process is aborted. This mechanism protects the system against rollback. The TBBR CoT has been updated to include this method as part of the authentication process. Two counters are used: one for the trusted world images and another for the non trusted world images. ** NEW PLATFORM APIs (mandatory when TBB is enabled) ** int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr); This API returns the non-volatile counter value stored in the platform. The cookie in the first argument may be used to select the counter in case the platform provides more than one (i.e. TBSA compliant platforms must provide trusted and non-trusted counters). This cookie is specified in the CoT. int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr); This API sets a new counter value. The cookie may be used to select the counter to be updated. An implementation of these new APIs for ARM platforms is also provided. The values are obtained from the Trusted Non-Volatile Counters peripheral. The cookie is used to pass the extension OID. This OID may be interpreted by the platform to know which counter must return. On Juno, The trusted and non-trusted counter values have been tied to 31 and 223, respectively, and cannot be modified. ** IMPORTANT ** THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN ORDER TO SUCCESSFULLY BUILD TF. Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
-
- 05 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
By default ARM TF is built with the '-pedantic' compiler flag, which helps detecting violations of the C standard. However, the mbed TLS library and its associated authentication module in TF used to fail building with this compiler flag. As a workaround, the mbed TLS authentication module makefile used to set the 'DISABLE_PEDANTIC' TF build flag. The compiler errors flagged by '-pedantic' in the mbed TLS library have been fixed between versions 1.3.9 and 2.2.0 and the library now properly builds with this compiler flag. This patch fixes the remaining compiler errors in the mbed TLS authentication module in TF and unsets the 'DISABLE_PEDANTIC' TF build flag. This means that TF is now always built with '-pedantic'. In particular, this patch: * Removes the final semi-colon in REGISTER_COT() macro. This semi-colon was causing the following error message: drivers/auth/tbbr/tbbr_cot.c:544:23: error: ISO C does not allow extra ';' outside of a function [-Werror=pedantic] This has been fixed both in the mbed TLS authentication module as well as in the certificate generation tool. Note that the latter code didn't need fixing since it is not built with '-pedantic' but the change has been propagated for consistency. Also fixed the REGISTER_KEYS() and REGISTER_EXTENSIONS() macros, which were suffering from the same issue. * Fixes a pointer type. It was causing the following error message: drivers/auth/mbedtls/mbedtls_crypto.c: In function 'verify_hash': drivers/auth/mbedtls/mbedtls_crypto.c:177:42: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] Change-Id: I7b7a04ef711efd65e17b5be26990d1a0d940257d
-
- 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
-
- 10 Dec, 2015 1 commit
-
-
Juan Castillo authored
The mbed TLS library has introduced some changes in the API from the 1.3.x to the 2.x releases. Using the 2.x releases requires some changes to the crypto and transport modules. This patch updates both modules to the mbed TLS 2.x API. All references to the mbed TLS library in the code or documentation have been updated to 'mbed TLS'. Old references to PolarSSL have been updated to 'mbed TLS'. User guide updated to use mbed TLS 2.2.0. NOTE: moving up to mbed TLS 2.x from 1.3.x is not backward compatible. Applying this patch will require an mbed TLS 2.x release to be used. Also note that the mbed TLS license changed to Apache version 2.0. Change-Id: Iba4584408653cf153091f2ca2ee23bc9add7fda4
-
- 09 Dec, 2015 1 commit
-
-
Yatharth Kochar authored
Firmware update(a.k.a FWU) feature is part of the TBB architecture. BL1 is responsible for carrying out the FWU process if platform specific code detects that it is needed. This patch adds support for FWU feature support in BL1 which is included by enabling `TRUSTED_BOARD_BOOT` compile time flag. This patch adds bl1_fwu.c which contains all the core operations of FWU, which are; SMC handler, image copy, authentication, execution and resumption. It also adds bl1.h introducing #defines for all BL1 SMCs. Following platform porting functions are introduced: int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size, unsigned int flags); This function can be used to add platform specific memory checks for the provided base/size for the given security state. The weak definition will invoke `assert()` and return -ENOMEM. __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved); This function can be used to initiate platform specific procedure to mark completion of the FWU process. The weak definition waits forever calling `wfi()`. plat_bl1_common.c contains weak definitions for above functions. FWU process starts when platform detects it and return the image_id other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in `bl1_main()`. NOTE: User MUST provide platform specific real definition for bl1_plat_mem_check() in order to use it for Firmware update. Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
-
- 25 Jun, 2015 3 commits
-
-
Juan Castillo authored
This patch adds a CoT based on the Trusted Board Boot Requirements document*. The CoT consists of an array of authentication image descriptors indexed by the image identifiers. A new header file with TBBR image identifiers has been added. Platforms that use the TBBR (i.e. ARM platforms) may reuse these definitions as part of their platform porting. PLATFORM PORT - IMPORTANT: Default image IDs have been removed from the platform common definitions file (common_def.h). As a consequence, platforms that used those common definitons must now either include the IDs provided by the TBBR header file or define their own IDs. *The NVCounter authentication method has not been implemented yet. Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
-
Juan Castillo authored
This patch adds the following mbedTLS based libraries: * Cryptographic library It is used by the crypto module to verify a digital signature and a hash. This library relies on mbedTLS to perform the cryptographic operations. mbedTLS sources must be obtained separately. Two key algorithms are currently supported: * RSA-2048 * ECDSA-SECP256R1 The platform is responsible for picking up the required algorithm by defining the 'MBEDTLS_KEY_ALG' variable in the platform makefile. Available options are: * 'rsa' (for RSA-2048) (default option) * 'ecdsa' (for ECDSA-SECP256R1) Hash algorithm currently supported is SHA-256. * Image parser library Used by the image parser module to extract the authentication parameters stored in X509v3 certificates. Change-Id: I597c4be3d29287f2f18b82846973afc142ee0bf0
-
Juan Castillo authored
This patch adds the authentication framework that will be used as the base to implement Trusted Board Boot in the Trusted Firmware. The framework comprises the following modules: - Image Parser Module (IPM) This module is responsible for interpreting images, check their integrity and extract authentication information from them during Trusted Board Boot. The module currently supports three types of images i.e. raw binaries, X509v3 certificates and any type specific to a platform. An image parser library must be registered for each image type (the only exception is the raw image parser, which is included in the main module by default). Each parser library (if used) must export a structure in a specific linker section which contains function pointers to: 1. Initialize the library 2. Check the integrity of the image type supported by the library 3. Extract authentication information from the image - Cryptographic Module (CM) This module is responsible for verifying digital signatures and hashes. It relies on an external cryptographic library to perform the cryptographic operations. To register a cryptographic library, the library must use the REGISTER_CRYPTO_LIB macro, passing function pointers to: 1. Initialize the library 2. Verify a digital signature 3. Verify a hash Failing to register a cryptographic library will generate a build time error. - Authentication Module (AM) This module provides methods to authenticate an image, like hash comparison or digital signatures. It uses the image parser module to extract authentication parameters, the crypto module to perform cryptographic operations and the Chain of Trust to authenticate the images. The Chain of Trust (CoT) is a data structure that defines the dependencies between images and the authentication methods that must be followed to authenticate an image. The Chain of Trust, when added, must provide a header file named cot_def.h with the following definitions: - COT_MAX_VERIFIED_PARAMS Integer value indicating the maximum number of authentication parameters an image can present. This value will be used by the authentication module to allocate the memory required to load the parameters in the image descriptor. Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178
-