- 25 Jun, 2015 6 commits
-
-
Juan Castillo authored
This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
-
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
-
Juan Castillo authored
This patch extends the platform port by adding an API that returns either the Root of Trust public key (ROTPK) or its hash. This is usually stored in ROM or eFUSE memory. The ROTPK returned must be encoded in DER format according to the following ASN.1 structure: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } In case the platform returns a hash of the key: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, keyDigest OCTET STRING } An implementation for ARM development platforms is provided in this patch. When TBB is enabled, the ROTPK hash location must be specified using the build option 'ARM_ROTPK_LOCATION'. Available options are: - 'regs' : return the ROTPK hash stored in the Trusted root-key storage registers. - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and BL2 binaries. This hash has been obtained from the development RSA public key located in 'plat/arm/board/common/rotpk'. On FVP, the number of MMU tables has been increased to map and access the ROTPK registers. A new file 'board_common.mk' has been added to improve code sharing in the ARM develelopment platforms. Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
-
Juan Castillo authored
The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
-
- 24 Jun, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch fixes the build time condition deciding whether the read-write data should be relocated from ROM to RAM. It was incorrectly using __DATA_ROM_START__, which is a linker symbol and not a compiler build flag. As a result, the relocation code was always compiled out. This bug has been introduced by the following patch: "Rationalize reset handling code" Change-Id: I1c8d49de32f791551ab4ac832bd45101d6934045
-
- 18 Jun, 2015 2 commits
-
-
Ryan Harkin authored
Add SP804 delay timer support to the FVP BSP. This commit simply provides the 3 constants needed by the SP804 delay timer driver and calls sp804_timer_init() in bl2_platform_setup(). The BSP does not currently use the delay timer functions. Note that the FVP SP804 is a normal world accessible peripheral and should not be used by the secure world after transition to the normal world. Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39 Co-authored-by: Dan Handley <dan.handley@arm.com>
-
Ryan Harkin authored
Add a delay timer driver for the ARM SP804 dual timer. This driver only uses the first timer, called timer 1 in the SP804 Technical Reference Manual (ARM DDI 0271D). To use this driver, the BSP must provide three constants: * The base address of the SP804 dual timer * The clock multiplier * The clock divider The BSP is responsible for calling sp804_timer_init(). The SP804 driver instantiates a constant timer_ops_t and calls the generic timer_init(). Change-Id: I49ba0a52bdf6072f403d1d0a20e305151d4bc086 Co-authored-by: Dan Handley <dan.handley@arm.com>
-
- 17 Jun, 2015 1 commit
-
-
Ryan Harkin authored
The API is simple. The BSP or specific timer driver creates an instance of timer_ops_t, fills in the timer specific data, then calls timer_init(). The timer specific data includes a function pointer to return the timer value and a clock multiplier/divider. The ratio of the multiplier and the divider is the clock frequency in MHz. After that, mdelay() or udelay() can be called to delay execution for the specified time (milliseconds or microseconds, respectively). Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c Co-authored-by: Dan Handley <dan.handley@arm.com>
-
- 09 Jun, 2015 2 commits
-
-
Sandrine Bailleux authored
For CSS based platforms, the constants MHU_SECURE_BASE and MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes. As such, they were misnamed because the mailboxes are completely unrelated to the MHU hardware. This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines. The address of the Trusted Mailboxes is now relative to the base of the Trusted SRAM. This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE, which is the address of the first memory region used for communication between AP and SCP. This is used by the BOM and SCPI protocols. Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
-
Sandrine Bailleux authored
Add a comment explaining what the SCP boot configuration information is on CSS based platforms like Juno. Also express its address relatively to the base of the Trusted SRAM rather than hard-coding it. Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b
-
- 04 Jun, 2015 2 commits
-
-
Sandrine Bailleux authored
The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
-
Sandrine Bailleux authored
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its use in ARM development platforms. If a different reset handling behavior is required between the first and subsequent invocations of the reset handling code, this should be detected at runtime. On Juno, the platform reset handler is now always compiled in. This means it is now executed twice on the cold boot path, first in BL1 then in BL3-1, and it has the same behavior in both cases. It is also executed twice on the warm boot path, first in BL1 then in the PSCI entrypoint code. Also update the documentation to reflect this change. NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER. Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
-
- 29 May, 2015 1 commit
-
-
Varun Wadekar authored
This patch adds driver for the 16550 UART interface. The driver is exposed as a console, which platforms can use to dump their boot/crash logs. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 27 May, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the primary cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in platform_is_primary_cpu(). Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa
-
- 19 May, 2015 1 commit
-
-
Achin Gupta authored
The ARM GIC driver treats the entire contents of the GICC_HPPIR as the interrupt ID instead of just bits[9:0]. This could result in an SGI being treated as a Group 1 interrupt on a GICv2 system. This patch introduces a mask to retrieve only the ID from a read of GICC_HPPIR, GICC_IAR and similar registers. The value read from these registers is masked with this constant prior to use as an interrupt ID. Fixes ARM-software/tf-issues#306 Change-Id: Ie3885157de33b71df9781a41f6ef015a30c4608d
-
- 28 Apr, 2015 3 commits
-
-
Dan Handley authored
Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
-
Dan Handley authored
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
-
Dan Handley authored
Add extern declarations of linker symbols to bl_common.h. These are used by platform ports to determine the memory layout of BL images. Adding the declarations to this file facilitates removal of these declarations from the platform porting source files in subsequent patches. Also remove the linker symbol declarations from common TSP source code. Change-Id: I8ed0426bc815317c4536b588e4e78bc15b4fe91c
-
- 27 Apr, 2015 3 commits
-
-
Dan Handley authored
Some assembly files containing macros are included like header files into other assembly files. This will cause assembler errors if they are included multiple times. Add header guards to assembly macro files to avoid assembler errors. Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69
-
Dan Handley authored
The required platform constant PLATFORM_CACHE_LINE_SIZE is unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the same information. CACHE_WRITEBACK_GRANULE is preferred since this is an architecturally defined term and allows comparison with the corresponding hardware register value. Replace all usage of PLATFORM_CACHE_LINE_SIZE with CACHE_WRITEBACK_GRANULE. Also, add a runtime assert in BL1 to check that the provided CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0. Change-Id: If87286be78068424217b9f3689be358356500dcd
-
Dan Handley authored
Region 0 is special in TZC-400. It is possible to set the access permissions for this but not the address range or filters to which the permissions apply. Add a function for setting the region 0 access permissions. Also add some VERBOSE logging and allow assembly files to include the TZC header. Change-Id: I4389261ba10a6e5e2e43ee93d55318dc507b6648
-
- 13 Apr, 2015 1 commit
-
-
Varun Wadekar authored
This patch removes the need for a shared buffer between the EL3 and S-EL1 levels. We now use the CPU registers, x0-x7, while passing data between the two levels. Since TLK is a 32-bit Trusted OS, tlkd has to unpack the arguments in the x0-x7 registers. TLK in turn gets these values via r0-r7. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 08 Apr, 2015 1 commit
-
-
Kévin Petit authored
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the assembler using the .size directive. To fulfil the above requirements, this patch introduces an 'endfunc' macro which contains the .endfunc and .size directives. It also adds a .func directive to the 'func' assembler macro. The .func/.endfunc have been used so the assembler can fail if endfunc is omitted. Fixes ARM-Software/tf-issues#295 Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc Signed-off-by: Kévin Petit <kevin.petit@arm.com>
-
- 31 Mar, 2015 5 commits
-
-
Varun Wadekar authored
This patch adds support to open/close secure sessions with Trusted Apps and later send commands/events. Modify TLK_NUM_FID to indicate the total number of FIDs available to the NS world. Change-Id: I3f1153dfa5510bd44fc25f1fee85cae475b1abf1 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch allows servicing of the non-secure world IRQs when the CPU is in the secure world. Once the interrupt is handled, the non-secure world issues the Resume FID to allow the secure payload complete the preempted standard FID. Change-Id: Ia52c41adf45014ab51d8447bed6605ca2f935587 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch adds functionality to translate virtual addresses from secure or non-secure worlds. This functionality helps Trusted Apps to share virtual addresses directly and allows the NS world to pass virtual addresses to TLK directly. Change-Id: I77b0892963e0e839c448b5d0532920fb7e54dc8e Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch registers NS memory buffer with the secure payload using two different functions IDs - REGISTER_LOGBUF, REGISTER_REQBUF. a. The SP uses the log-buffer to store its activity logs, in a pre-decided format. This helps in debugging secure payload's issues. b. The SP uses the req-buffer to get the parameters required by sessions with Trusted Applications. Change-Id: I6b0247cf7790524132ee0da24f1f35b1fccec5d5 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
TLK Dispatcher (tlkd) is based on the tspd and is the glue required to run TLK as a Secure Payload with the Trusted Firmware. Change-Id: I69e573d26d52342eb049feef773dd7d2a506f4ab Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 27 Mar, 2015 2 commits
-
-
Soby Mathew authored
This patch removes the `owner` field in bakery_lock_t structure which is the data structure used in the bakery lock implementation that uses coherent memory. The assertions to protect against recursive lock acquisition were based on the 'owner' field. They are now done based on the bakery lock ticket number. These assertions are also added to the bakery lock implementation that uses normal memory as well. Change-Id: If4850a00dffd3977e218c0f0a8d145808f36b470
-
Soby Mathew authored
This patch optimizes the data structure used with the bakery lock implementation for coherent memory to save memory and minimize memory accesses. These optimizations were already part of the bakery lock implementation for normal memory and this patch now implements it for the coherent memory implementation as well. Also included in the patch is a cleanup to use the do-while loop while waiting for other contenders to finish choosing their tickets. Change-Id: Iedb305473133dc8f12126726d8329b67888b70f1
-
- 18 Mar, 2015 1 commit
-
-
Vikram Kanigiri authored
This patch adds support for ARM Cortex-A72 processor in the CPU specific framework. Change-Id: I5986855fc1b875aadf3eba8c36e989d8a05e5175
-
- 16 Mar, 2015 3 commits
-
-
Vikram Kanigiri authored
This patch updates the FVP and Juno platform ports to use the common driver for ARM Cache Coherent Interconnects. Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542
-
Vikram Kanigiri authored
Even though both CCI-400 and CCI-500 IPs have different configurations with respect to the number and types of supported interfaces, their register offsets and programming sequences are similar. This patch creates a common driver for enabling and disabling snoop transactions and DVMs with both the IPs. New platform ports which implement one of these IPs should use this common driver. Existing platform ports which implement CCI-400 should migrate to the common driver as the standalone CCI-400 will be deprecated in the future. Change-Id: I3ccd0eb7b062922d2e4a374ff8c21e79fa357556
-
Vikram Kanigiri authored
This patch defines the ARRAY_SIZE macro for calculating number of elements in an array and uses it where appropriate. Change-Id: I72746a9229f0b259323972b498b9a3999731bc9b
-
- 13 Mar, 2015 1 commit
-
-
Vikram Kanigiri authored
The cpu-ops pointer was initialized before enabling the data cache in the cold and warm boot paths. This required a DCIVAC cache maintenance operation to invalidate any stale cache lines resident in other cpus. This patch moves this initialization to the bl31_arch_setup() function which is always called after the data cache and MMU has been enabled. This change removes the need: 1. for the DCIVAC cache maintenance operation. 2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND call since memory contents are always preserved in this case. Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6
-
- 06 Mar, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch modifies the declarations of the functions printf() et al. and adds the right GCC attribute to request the compiler to check the type of the arguments passed to these functions against the given format string. This will ensure that the compiler outputs warning messages like the following whenever it detects an inconsistency: file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’ It also fixes the type mismatch inconsistencies that it revealed across the code base. NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES. Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6
-
- 12 Feb, 2015 1 commit
-
-
Soby Mathew authored
This patch removes the plat_get_max_afflvl() platform API and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL. This is done because the maximum affinity level for a platform is a static value and it is more efficient for it to be defined as a platform macro. NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT Fixes ARM-Software/tf-issues#265 Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf
-
- 28 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch provides an API to access the authentication module that will be used to verify the authenticity of the images loaded into memory as part of the Trusted Board Boot process. To include the authentication module as part of the build, set the boolean build option TRUSTED_BOARD_BOOT. One single authentication module must be registered at build time by setting the build option AUTH_MOD=<mod_name>. All authentication modules will be located in 'common/auth/<mod_name>' and must present the <mod_name>.mk file that will be included by the build system to compile the module sources. To create an authentication module, an instance of auth_mod_t called 'auth_mod' must be declared in the module sources. The initialization and verification functions provided by the module will be exported through the function pointers specified when declaring this instance. If an authentication module includes third party sources that do not adhere to the C99 standard, the -pedantic option may be removed from the build options by setting the flag DISABLE_PEDANTIC in the module file <mod_name>.mk. Change-Id: I080bb04bd421029bcdf22ec2c63807afbf061dcd
-