FWU: Add Generic Firmware Update framework support in BL1

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

FWU: Add Generic Firmware Update framework support in BL1

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

show more ...

Remove `RUN_IMAGE` usage as opcode passed to next EL.

The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to
make a request to BL1 to execute BL31. But BL2 also uses it as
opcode to che

Remove `RUN_IMAGE` usage as opcode passed to next EL.

The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to
make a request to BL1 to execute BL31. But BL2 also uses it as
opcode to check if it is allowed to execute which is not the
intended usage of `RUN_IMAGE` SMC.

This patch removes the usage of `RUN_IMAGE` as opcode passed to
next EL to check if it is allowed to execute.

Change-Id: I6aebe0415ade3f43401a4c8a323457f032673657

show more ...

CSS: Enable booting of EL3 payloads

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the

CSS: Enable booting of EL3 payloads

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.

Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.

The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.

The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.

The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.

This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.

Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077

show more ...

Add optional platform error handler API

This patch adds an optional API to the platform port:

void plat_error_handler(int err) __dead2;

The platform error handler is called when there is a spe

Add optional platform error handler API

This patch adds an optional API to the platform port:

void plat_error_handler(int err) __dead2;

The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.

The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:

-EAUTH : a certificate or image could not be authenticated
(when Trusted Board Boot is enabled)
-ENOENT : the requested image or certificate could not be found
or an IO error was detected
-ENOMEM : resources exhausted. Trusted Firmware does not use
dynamic memory, so this error is usually an indication
of an incorrect array size

A default weak implementation of this function has been provided.
It simply implements an infinite loop.

Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3

show more ...

Use standard errno definitions in load_auth_image()

This patch replaces custom definitions used as return values for
the load_auth_image() function with standard error codes defined
in errno.h. The

Use standard errno definitions in load_auth_image()

This patch replaces custom definitions used as return values for
the load_auth_image() function with standard error codes defined
in errno.h. The custom definitions have been removed.

It also replaces the usage of IO framework error custom definitions,
which have been deprecated. Standard errno definitions are used
instead.

Change-Id: I1228477346d3876151c05b470d9669c37fd231be

show more ...

Make generic code work in presence of system caches

On the ARMv8 architecture, cache maintenance operations by set/way on the last
level of integrated cache do not affect the system cache. This mean

Make generic code work in presence of system caches

On the ARMv8 architecture, cache maintenance operations by set/way on the last
level of integrated cache do not affect the system cache. This means that such a
flush or clean operation could result in the data being pushed out to the system
cache rather than main memory. Another CPU could access this data before it
enables its data cache or MMU. Such accesses could be serviced from the main
memory instead of the system cache. If the data in the sysem cache has not yet
been flushed or evicted to main memory then there could be a loss of
coherency. The only mechanism to guarantee that the main memory will be updated
is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
(System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).

This patch removes the reliance of Trusted Firmware on the flush by set/way
operation to ensure visibility of data in the main memory. Cache maintenance
operations by MVA are now used instead. The following are the broad category of
changes:

1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
initialised. This ensures that any stale cache lines at any level of cache
are removed.

2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
visible to secondary CPUs using a cache clean operation by MVA.

3. Cache maintenance by set/way operations are only used prior to power down.

NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.

Fixes ARM-software/tf-issues#205

Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a

show more ...

Merge pull request #368 from jcastillo-arm/jc/genfw/1126

TBB: abort boot if BL3-2 cannot be authenticated

TBB: abort boot if BL3-2 cannot be authenticated

BL3-2 image (Secure Payload) is optional. If the image cannot be
loaded a warning message is printed and the boot process continues.
According to the

TBB: abort boot if BL3-2 cannot be authenticated

BL3-2 image (Secure Payload) is optional. If the image cannot be
loaded a warning message is printed and the boot process continues.
According to the TBBR document, this behaviour should not apply in
case of an authentication error, where the boot process should be
aborted.

This patch modifies the load_auth_image() function to distinguish
between a load error and an authentication error. The caller uses
the return value to abort the boot process or continue.

In case of authentication error, the memory region used to store
the image is wiped clean.

Change-Id: I534391d526d514b2a85981c3dda00de67e0e7992

show more ...

PSCI: Migrate TF to the new platform API and CM helpers

This patch migrates the rest of Trusted Firmware excluding Secure Payload and
the dispatchers to the new platform and context management API.

PSCI: Migrate TF to the new platform API and CM helpers

This patch migrates the rest of Trusted Firmware excluding Secure Payload and
the dispatchers to the new platform and context management API. The per-cpu
data framework APIs which took MPIDRs as their arguments are deleted and only
the ones which take core index as parameter are retained.

Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d

show more ...

TBB: switch to the new authentication framework

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto

TBB: switch to the new authentication framework

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

show more ...

TBB: add authentication framework

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 foll

TBB: add authentication framework

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

show more ...

Use numbers to identify images instead of names

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 t

Use numbers to identify images instead of names

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

show more ...

Panic if platform specific BL3-0 handling fails

The return value of bl2_plat_handle_bl30() used to be ignored.
This patch modifies the function load_bl30() so that it now
checks this return value an

Panic if platform specific BL3-0 handling fails

The return value of bl2_plat_handle_bl30() used to be ignored.
This patch modifies the function load_bl30() so that it now
checks this return value and returns it to bl2_main().

This patch also unifies the error handling code across the
load_blx() functions so that they return a status code in all
cases and bl2_main() has the sole responsibility of panicking
if appropriate.

Change-Id: I2b26cdf65afa443b48c7da1fa7da8db956071bfb

show more ...

Add support to indicate size and end of assembly functions

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
ass

Add support to indicate size and end of assembly functions

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>

show more ...

TBB: authenticate BL3-x images and certificates

This patch adds support to authenticate the Trusted Key certificate
and the BL3-x certificates and images at BL2.

Change-Id: I69a8c13a14c8da8b75f9309

TBB: authenticate BL3-x images and certificates

This patch adds support to authenticate the Trusted Key certificate
and the BL3-x certificates and images at BL2.

Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd

show more ...

Remove coherent memory from the BL memory maps

This patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The p

Remove coherent memory from the BL memory maps

This patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The patch also adds necessary
documentation for coherent memory removal in firmware-design,
porting and user guides.

Fixes ARM-Software/tf-issues#106

Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773

show more ...

Bug fix: initialize bl30_image_info fields before use

This patch initializes the version field in the bl30_image_info
structure when loading BL30. This initialization must be done before
calling loa

Bug fix: initialize bl30_image_info fields before use

This patch initializes the version field in the bl30_image_info
structure when loading BL30. This initialization must be done before
calling load_image().

Fixes ARM-software/tf-issues#274

Change-Id: I74a05167d66fff51d257ad611abc7b5436e5d912

show more ...

Juno: Use TZC-400 driver calls

This patch replaces direct accesses to the TZC-400 registers by the
appropiate calls to the generic driver available in the Trusted
Firmware in order to initialize the

Juno: Use TZC-400 driver calls

This patch replaces direct accesses to the TZC-400 registers by the
appropiate calls to the generic driver available in the Trusted
Firmware in order to initialize the TrustZone Controller.

Functions related to the initialization of the secure memory,
like the TZC-400 configuration, have been moved to a new file
'plat_security.c'. This reorganization makes easier to set up
the secure memory from any BL stage.

TZC-400 initialization has been moved from BL1 to BL2 because BL1
does not access the non-secure memory. It is BL2's responsibility
to enable and configure the TZC-400 before loading the next BL
images.

In Juno, BL3-0 initializes some of the platform peripherals, like
the DDR controller. Thus, BL3-0 must be loaded before configuring
the TrustZone Controller. As a consequence, the IO layer
initialization has been moved to early platform initialization.

Fixes ARM-software/tf-issues#234

Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e

show more ...

Fix LENGTH attribute value in linker scripts

This patch fixes the incorrect value of the LENGTH attribute in
the linker scripts. This attribute must define the memory size, not
the limit address.

F

Fix LENGTH attribute value in linker scripts

This patch fixes the incorrect value of the LENGTH attribute in
the linker scripts. This attribute must define the memory size, not
the limit address.

Fixes ARM-software/tf-issues#252

Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46

show more ...

Merge pull request #189 from achingupta/ag/tf-issues#153

Unmask SError interrupt and clear SCR_EL3.EA bit

Unmask SError interrupt and clear SCR_EL3.EA bit

This patch disables routing of external aborts from lower exception levels to
EL3 and ensures that a SError interrupt generated as a result of execut

Unmask SError interrupt and clear SCR_EL3.EA bit

This patch disables routing of external aborts from lower exception levels to
EL3 and ensures that a SError interrupt generated as a result of execution in
EL3 is taken locally instead of a lower exception level.

The SError interrupt is enabled in the TSP code only when the operation has not
been directly initiated by the normal world. This is to prevent the possibility
of an asynchronous external abort which originated in normal world from being
taken when execution is in S-EL1.

Fixes ARM-software/tf-issues#153

Change-Id: I157b996c75996d12fd86d27e98bc73dd8bce6cd5

show more ...

Merge pull request #184 from jcastillo-arm/jc/tf-issues/100

FVP: make usage of Trusted DRAM optional at build time

Rationalize console log output

Fix the following issues with the console log output:

* Make sure the welcome string is the first thing in the log output
(during normal boot).
* Prefix each message

Rationalize console log output

Fix the following issues with the console log output:

* Make sure the welcome string is the first thing in the log output
(during normal boot).
* Prefix each message with the BL image name so it's clear which
BL the output is coming from.
* Ensure all output is wrapped in one of the log output macros so it can
be easily compiled out if necessary. Change some of the INFO() messages
to VERBOSE(), especially in the TSP.
* Create some extra NOTICE() and INFO() messages during cold boot.
* Remove all usage of \r in log output.

Fixes ARM-software/tf-issues#231

Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3

show more ...

FVP: apply new naming conventions to memory regions

Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
Secure RAM at add

FVP: apply new naming conventions to memory regions

Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM

BLn_BASE and BLn_LIMIT definitions have been updated and are based on
these new memory regions.

The available memory for each bootloader in the linker script is
defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
region.

TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
the platform porting.

FVP common definitions are defined in fvp_def.h while platform_def.h
contains exclusively (with a few exceptions) the definitions that are
mandatory in the porting guide. Therefore, platform_def.h now includes
fvp_def.h instead of the other way around.

Porting guide has been updated to reflect these changes.

Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05

show more ...

Call platform_is_primary_cpu() only from reset handler

The purpose of platform_is_primary_cpu() is to determine after reset
(BL1 or BL3-1 with reset handler) if the current CPU must follow the
cold

Call platform_is_primary_cpu() only from reset handler

The purpose of platform_is_primary_cpu() is to determine after reset
(BL1 or BL3-1 with reset handler) if the current CPU must follow the
cold boot path (primary CPU), or wait in a safe state (secondary CPU)
until the primary CPU has finished the system initialization.

This patch removes redundant calls to platform_is_primary_cpu() in
subsequent bootloader entrypoints since the reset handler already
guarantees that code is executed exclusively on the primary CPU.

Additionally, this patch removes the weak definition of
platform_is_primary_cpu(), so the implementation of this function
becomes mandatory. Removing the weak symbol avoids other
bootloaders accidentally picking up an invalid definition in case the
porting layer makes the real function available only to BL1.

The define PRIMARY_CPU is no longer mandatory in the platform porting
because platform_is_primary_cpu() hides the implementation details
(for instance, there may be platforms that report the primary CPU in
a system register). The primary CPU definition in FVP has been moved
to fvp_def.h.

The porting guide has been updated accordingly.

Fixes ARM-software/tf-issues#219

Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e

show more ...