Following discussions in the reviews of the patch that introduced
plat_convert_pk() function [1], it was decided to deprecate it to
avoid weak function declaration.
A new optional function pointer convert_pk is added to crypto_lib_desc_t.
A new function crypto_mod_convert_pk() will either call
crypto_lib_desc.convert_pk() if it is defined, or do the same
as what was done by the weak function otherwise.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17174
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: I9358867f8bfd5e96b5ee238c066877da368e43c6
Compared the full ROTPK with the ROTPK obtained from the certificate
when the platform supports full ROTPK instead of hash of ROTPK.
Additionally, changed the code to verify the ROTPK before relying on
it for signature verification.
Change-Id: I52bb9deb1a1dd5b184d3156bddad14c238692de7
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
auth_nvctr() does not check that the buffer provided is long enough to
hold an ASN.1 INTEGER, or even that the buffer is non-empty. Since
auth_nvctr() will only ever read 6 bytes, it is possible to read up to
6 bytes past the end of the buffer.
This out-of-bounds read turns out to be harmless. The only caller of
auth_nvctr() always passes a pointer into an X.509 TBSCertificate, and
all in-tree chains of trust require that the certificate’s signature has
already been validated. This means that the signature algorithm
identifier is at least 4 bytes and the signature itself more than that.
Therefore, the data read will be from the certificate itself. Even if
the certificate signature has not been validated, an out-of-bounds read
is still not possible. Since there are at least two bytes (tag and
length) in both the signature algorithm ID and the signature itself, an
out-of-bounds read would require that the tag byte of the signature
algorithm ID would need to be either the tag or length byte of the
DER-encoded nonvolatile counter. However, this byte must be
(MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE) (0x30), which is
greater than 4 and not equal to MBEDTLS_ASN1_INTEGER (2). Therefore,
auth_nvctr() will error out before reading the integer itself,
preventing an out-of-bounds read.
Change-Id: Ibdf1af702fbeb98a94c0c96456ebddd3d392ad44
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
In some platform the digest of the public key saved in the OTP is not
the digest of the exact same public key buffer needed to check the
signature. Typically, platform checks signature using the DER ROTPK
whereas some others add some related information. Add a new platform
weak function to transform the public key buffer used by
verify_signature to a platform specific public key.
Mark this new weak function as deprecated as it will be replaced
by another framework implementation.
Change-Id: I71017b41e3eca9398cededf317ad97e9b511be5f
Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@st.com>
Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com>
Measured-Boot and Trusted-Boot are orthogonal to each other and hence
removed dependency of Trusted-Boot on Measured-Boot by making below
changes -
1. BL1 and BL2 main functions are used for initializing Crypto module
instead of the authentication module
2. Updated Crypto module registration macro for MEASURED_BOOT with only
necessary callbacks for calculating image hashes
3. The 'load_auth_image' function is now used for the image measurement
during Trusted or Non-Trusted Boot flow
Change-Id: I3570e80bae8ce8f5b58d84bd955aa43e925d9fff
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Avoided NV counter update when the system is running in
trial run state.
Change-Id: I5da6a6760f8a9faff777f2ff879156e9c3c76726
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Platform NV counter get updated (if cert NV counter > plat NV counter)
before authenticating the certificate if the platform specifies NV
counter method before signature authentication in its CoT, and this
provides an opportunity for a tempered certificate to upgrade the
platform NV counter. This is theoretical issue, as in practice none
of the standard CoT (TBBR, dualroot) or upstream platforms ones (NXP)
exercised this issue.
To fix this issue, modified the auth_nvctr method to do only NV
counter check, and flags if the NV counter upgrade is needed or not.
Then ensured that the platform NV counter gets upgraded with the NV
counter value from the certificate only after that certificate gets
authenticated.
This change is verified manually by modifying the CoT that specifies
certificate with:
1. NV counter authentication before signature authentication
method
2. NV counter authentication method only
Change-Id: I1ad17f1a911fb1035a1a60976cc26b2965b05166
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Introduce the Firmware CONfiguration Framework (fconf).
The fconf is an abstraction layer for platform specific data, allowing
a "property" to be queried and a value retrieved without the requesting
entity knowing what backing store is being used to hold the data.
The default backing store used is C structure. If another backing store
has to be used, the platform integrator needs to provide a "populate()"
function to fill the corresponding C structure.
The "populate()" function must be registered to the fconf framework with
the "FCONF_REGISTER_POPULATOR()". This ensures that the function would
be called inside the "fconf_populate()" function.
A two level macro is used as getter:
- the first macro takes 3 parameters and converts it to a function
call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c).
- the second level defines a__b_getter(c) to the matching C structure,
variable, array, function, etc..
Ex: Get a Chain of trust property:
1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id)
2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id]
Change-Id: Id394001353ed295bc680c3f543af0cf8da549469
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
In further patches, we wish to enable -wredundant-decls check as
part of warning flags by default.
Change-Id: I43410d6dbf40361a503c16d94ccf0f4cf29615b7
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
The chain of trust description and the pointer pointing to its first
element were incompatible, thus requiring an explicit type cast for
the assignment.
- cot_desc was an array of
const pointers to const image descriptors.
- cot_desc_ptr was a const pointer to
(non-constant) pointers to const image descriptors.
Thus, trying to assign cot_desc to cot_desc_ptr (with no cast) would
generate the following compiler warning:
drivers/auth/tbbr/tbbr_cot.c:826:14: warning: initialization discards
‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
REGISTER_COT(cot_desc);
^~~~~~~~
Change-Id: Iae62dd1bdb43fe379e3843d96461d47cc2f68a06
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This changes the auth_img_desc_t struct to have pointers to struct
arrays instead of struct arrays. This saves memory as many of these
were never used, and can be NULL pointers. Note the memory savings are
only when these arrays are not initialised, as it is assumed these
arrays are fixed length. A possible future optimisation could allow for
variable length.
memory diff:
bl1: bl2:
text text
-12 -12
bss bss
-1463 0
data data
-56 -48
rodata rodata
-5688 -2592
total total
-7419 -2652
Change-Id: I8f9bdedf75048b8867f40c56381e3a6dc6402bcc
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
When Trusted Board Boot is enabled, we need to specify the Chain of
Trust (CoT) of the BL1 and BL2 images. A CoT consists of an array
of image descriptors. The authentication module assumes that each
image descriptor in this array is indexed by its unique image
identifier. For example, the Trusted Boot Firmware Certificate has to
be at index [TRUSTED_BOOT_FW_CERT_ID].
Unique image identifiers may not necessarily be consecutive. Also,
a given BL image might not use all image descriptors. For example, BL1
does not need any of the descriptors related to BL31. As a result, the
CoT array might contain holes, which unnecessarily takes up space in
the BL binary.
Using pointers to auth_img_desc_t structs (rather than structs
themselves) means these unused elements only use 1 pointer worth of
space, rather than one struct worth of space. This patch also changes
the code which accesses this array to reflect the change to pointers.
Image descriptors not needed in BL1 or BL2 respectively are also
ifdef'd out in this patch. For example, verifying the BL31 image is
the responsibility of BL2 so BL1 does not need any of the data
structures describing BL31.
memory diff:
bl1: bl2:
text text
-20 -20
bss bss
-1463 0
data data
-256 -48
rodata rodata
-5240 -1952
total total
-6979 -2020
Change-Id: I163668b174dc2b9bbb183acec817f2126864aaad
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
Improved support for W=2 compilation flag by solving some nested-extern
and sign-compare warnings.
The libraries are compiling with warnings (which turn into errors with
the Werror flag).
Outside of libraries, some warnings cannot be fixed.
Change-Id: I06b1923857f2a6a50e93d62d0274915b268cef05
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Rule 8.3: All declarations of an object or function shall
use the same names and type qualifiers
Fixed for:
make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all
Change-Id: Ia34fe1ae1f142e89c9a6c19831e3daf4d28f5831
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
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>
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().
FixesARM-software/tf-issues#426
Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
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.
FixesARM-software/tf-issues#381
Change-Id: Icbbffab6bff8ed76b72431ee21337f550d8fdbbb
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
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
