summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-07-17Merge pull request #336 from danh-arm/sb/move-user-guide-to-linaro-releasedanh-arm
Update user guide to use Linaro releases
2015-07-17Merge pull request #335 from jcastillo-arm/jc/sh_writedanh-arm
Fix bug in semihosting write function
2015-07-17Merge pull request #332 from jcastillo-arm/jc/tf-issues/214danh-arm
Use uintptr_t as base address type in ARM driver APIs
2015-07-17Tegra: Exclude coherent memory region from memory mapVarun Wadekar
This patch sets the 'USE_COHERENT_MEM' flag to '0', so that the coherent memory region will not be included in the memory map. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-16Fix bug in semihosting write functionJuan Castillo
The return value from the SYS_WRITE semihosting operation is 0 if the call is successful or the number of bytes not written, if there is an error. The implementation of the write function in the semihosting driver treats the return value as the number of bytes written, which is wrong. This patch fixes it. Change-Id: Id39dac3d17b5eac557408b8995abe90924c85b85
2015-07-16TBB: rework cert_create tool to follow a data driven approachJuan Castillo
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
2015-07-15Update user guide to use Linaro releasesSandrine Bailleux
Linaro produce monthly software releases for the Juno and AEMv8-FVP platforms. These provide an integrated set of software components that have been tested together on these platforms. From now on, it is recommend that Trusted Firmware developers use the Linaro releases (currently 15.06) as a baseline for the dependent software components: normal world firmware, Linux kernel and device tree, file system as well as any additional micro-controller firmware required by the platform. This patch updates the user guide to document this new process. It changes the instructions to get the source code of the full software stack (including Trusted Firmware) and updates the dependency build instructions to make use of the build scripts that the Linaro releases provide. Change-Id: Ia8bd043f4b74f1e1b10ef0d12cc8a56ed3c92b6e
2015-07-09Use uintptr_t as base address type in ARM driver APIsJuan Castillo
This patch changes the type of the base address parameter in the ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The uintptr_t type allows coverage of the whole memory space and to perform arithmetic operations on the addresses. ARM platform code has also been updated to use uintptr_t as GIC base address in the configuration. Fixes ARM-software/tf-issues#214 Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1
2015-07-07Merge pull request #329 from vwadekar/tegra-system-suspend-v3Achin Gupta
Implement get_sys_suspend_power_state() handler for Tegra
2015-07-06Implement get_sys_suspend_power_state() handler for TegraVarun Wadekar
This patch implements the get_sys_suspend_power_state() handler required by the PSCI SYSTEM_SUSPEND API. The intent of this handler is to return the appropriate State-ID field which can be utilized in `affinst_suspend()` to suspend to system affinity level. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-02Merge pull request #324 from soby-mathew/sm/sys_suspenddanh-arm
PSCI: Add SYSTEM_SUSPEND API support
2015-07-01Merge pull request #326 from jcastillo-arm/jc/tbb_ecdsaAchin Gupta
TBB: build 'cert_create' with ECDSA only if OpenSSL supports it
2015-07-01TBB: build 'cert_create' with ECDSA only if OpenSSL supports itJuan Castillo
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
2015-06-25Merge pull request #315 from jcastillo-arm/jc/tbb_tmp9danh-arm
Authentication Framework
2015-06-25TBB: add authentication framework documentationJuan Castillo
This patch updates the user guide, adding instructions to build the Trusted Firmware with Trusted Board Support using the new framework. It also provides documentation about the framework itself, including a detailed section about the TBBR implementation using the framework. Change-Id: I0849fce9c5294cd4f52981e7a8423007ac348ec6
2015-06-25TBB: delete deprecated plat_match_rotpk()Juan Castillo
The authentication framework deprecates plat_match_rotpk() in favour of plat_get_rotpk_info(). This patch removes plat_match_rotpk() from the platform port. Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
2015-06-25TBB: delete deprecated PolarSSL authentication moduleJuan Castillo
After updating the main authentication module to use the transport and crypto modules and the CoT description, the PolarSSL authentication module is no longer required. This patch deletes it. Change-Id: I8ba1e13fc1cc7b2fa9df14ff59eb798f0460b878
2015-06-25TBB: switch to the new authentication frameworkJuan Castillo
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
2015-06-25TBB: add ECDSA support to the certificate generation toolJuan Castillo
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
2015-06-25TBB: add TBBR Chain of TrustJuan Castillo
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
2015-06-25TBB: add mbedTLS authentication related librariesJuan Castillo
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
2015-06-25TBB: add authentication frameworkJuan Castillo
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
2015-06-25TBB: add platform API to read the ROTPK informationJuan Castillo
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
2015-06-25Use numbers to identify images instead of namesJuan Castillo
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
2015-06-25TBB: replace assert() with runtime checks in PolarSSL moduleJuan Castillo
Using assert() to check the length of keys and hashes included in a certificate is not a safe approach because assert() only applies to debug builds. A malformed certificate could exploit security flaws in release binaries due to buffer overflows. This patch replaces assert() with runtime checkings in the PolarSSL authentication module, so malformed certificates can not cause a memory overflow. Change-Id: I42ba912020595752c806cbd242fe3c74077d993b
2015-06-25TBB: use ASN.1 type DigestInfo to represent hashesJuan Castillo
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
2015-06-25TBB: add build option to save private keysJuan Castillo
This patch adds a boolean build option 'SAVE_KEYS' to indicate the certificate generation tool that it must save the private keys used to establish the chain of trust. This option depends on 'CREATE_KEYS' to be enabled. Default is '0' (do not save). Because the same filenames are used as outputs to save the keys, they are no longer a dependency to the cert_tool. This dependency has been removed from the Makefile. Documentation updated accordingly. Change-Id: I67ab1c2b1f8a25793f0de95e8620ce7596a6bc3b
2015-06-24Merge pull request #325 from sandrine-bailleux/sb/fix-rw-data-relocationdanh-arm
Bug fix: Build time condition to relocate RW data
2015-06-24Bug fix: Build time condition to relocate RW dataSandrine Bailleux
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
2015-06-24Merge pull request #321 from vwadekar/tegra-gic-implementation-v1danh-arm
Add missing features to the Tegra GIC driver
2015-06-24Merge pull request #310 from sandrine-bailleux/sb/tf-issue-304-phase1danh-arm
Enhance BL3-1 entrypoint handling to support non-TF boot firmware - Phase 1
2015-06-22PSCI: Add SYSTEM_SUSPEND API supportSoby Mathew
This patch adds support for SYSTEM_SUSPEND API as mentioned in the PSCI 1.0 specification. This API, on being invoked on the last running core on a supported platform, will put the system into a low power mode with memory retention. The psci_afflvl_suspend() internal API has been reused as most of the actions to suspend a system are the same as invoking the PSCI CPU_SUSPEND API with the target affinity level as 'system'. This API needs the 'power state' parameter for the target low power state. This parameter is not passed by the caller of the SYSTEM_SUSPEND API. Hence, the platform needs to implement the get_sys_suspend_power_state() platform function to provide this information. Also, the platform also needs to add support for suspending the system to the existing 'plat_pm_ops' functions: affinst_suspend() and affinst_suspend_finish(). Change-Id: Ib6bf10809cb4e9b92f463755608889aedd83cef5
2015-06-22Add missing features to the Tegra GIC driverVarun Wadekar
In order to handle secure/non-secure interrupts, overload the plat_ic_* functions and copy GIC helper functions from arm_gic.c. Use arm_gic.c as the reference to add Tegra's GIC helper functions. Now that Tegra has its own GIC implementation, we have no use for plat_gic.c and arm_gic.c files. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-06-19Merge pull request #322 from athoelke/at/fix-bl1-assertionsdanh-arm
Fix incorrect assertions in bl1_main()
2015-06-19Merge pull request #323 from athoelke/at/fix-aff-inst-overflowdanh-arm
Fix integer extension in mpidr_set_aff_inst()
2015-06-19Fix incorrect assertions in bl1_main()Andrew Thoelke
The validation of the caching enable state in bl1_main() was incorrect resulting in the state not being checked. Using the right operator fixes this. Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51
2015-06-19Fix integer extension in mpidr_set_aff_inst()Andrew Thoelke
mpidr_set_aff_inst() is left shifting an int constant and an unsigned char value to construct an MPIDR. For affinity level 3 a shift of 32 would result in shifting out of the 32-bit type and have no effect on the MPIDR. These values need to be extended to unsigned long before shifting to ensure correct results for affinity level 3. Change-Id: I1ef40afea535f14cfd820c347a065a228e8f4536
2015-06-18Merge pull request #320 from danh-arm/rh/timer-api-v10danh-arm
Add delay timer API v10
2015-06-18FVP: Add SP804 delay timerRyan Harkin
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>
2015-06-18Add SP804 delay timer driverRyan Harkin
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>
2015-06-18Merge pull request #319 from vwadekar/tegra-video-mem-aperture-v3danh-arm
Reserve a Video Memory aperture in DRAM memory
2015-06-17Add a simple delay timer driver APIRyan Harkin
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>
2015-06-12Merge pull request #317 from vwadekar/run-bl32-on-tegra-v3Achin Gupta
Run bl32 on tegra v3
2015-06-12Reserve a Video Memory aperture in DRAM memoryVarun Wadekar
This patch adds support to reserve a memory carveout region in the DRAM on Tegra SoCs. The memory controller provides specific registers to specify the aperture's base and size. This aperture can also be changed dynamically in order to re-size the memory available for DRM video playback. In case of the new aperture not overlapping the previous one, the previous aperture has to be cleared before setting up the new one. This means we do not "leak" any video data to the NS world. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-06-11Move dispatcher documents to the docs/spd folderVarun Wadekar
This patch moves the optee-dispatcher.md and tlk-dispatcher.md to docs/spd. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-06-11Boot Trusted OS' on Tegra SoCsVarun Wadekar
This patch adds support to run a Trusted OS during boot time. The previous stage bootloader passes the entry point information in the 'bl32_ep_info' structure, which is passed over to the SPD. The build system expects the dispatcher to be passed as an input parameter using the 'SPD=<dispatcher>' option. The Tegra docs have also been updated with this information. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-06-09Merge pull request #314 from sandrine-bailleux/sb/css-data-structsdanh-arm
Clarify some CSS data structures
2015-06-09Merge pull request #312 from jcastillo-arm/jc/tf-issues/308danh-arm
Fix build option 'ARM_TSP_RAM_LOCATION' in user guide
2015-06-09CSS: Remove the constants MHU_SECURE_BASE/SIZESandrine Bailleux
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
2015-06-09CSS: Clarify what the SCP boot config isSandrine Bailleux
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