Incorporate a timing side-channel attack into the TF-A generic
threat model. There is no software mitigation measures in TF-A
against this specific type of attack.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I10e53f8ed85a6da32de4fa6a210805f950018102
Exclude the threat of power analysis side-channel attacks
from consideration in the TF-A generic threat model.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I5b245f33609fe8948e473ce4484898db5ff8db4d
Software supply chain attacks aim to inject malicious code into a
software product. There are several ways a malicious code can be
injected into a software product (open-source project).
These include:
- Malicious code commits
- Malicious dependencies
- Malicious toolchains
This document provides analysis of software supply chain attack
threats for the TF-A project
Change-Id: I03545d65a38dc372f3868a16c725b7378640a771
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Added an assumption in generic threat model that platform's hardware
conforms the Platform Security Requirements specification.
Change-Id: I753287feec1cd459edfd3d1c103e0e701827cc05
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Arm Confidential Compute Architecture (Arm CCA) support, underpinned by
Arm Realm Management Extension (RME) support, brings in a few important
software and hardware architectural changes in TF-A, which warrants a
new security analysis of the code base. Results of this analysis are
captured in a new threat model document, provided in this patch.
The main changes introduced in TF-A to support Arm CCA / RME are:
- Presence of a new threat agent: realm world clients.
- Availability of Arm CCA Hardware Enforced Security (HES) to support
measured boot and trusted boot.
- Configuration of the Granule Protection Tables (GPT) for
inter-world memory protection.
This is only an initial version of the threat model and we expect to
enrich it in the future.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Co-authored-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Iab84dc724df694511508f90dc76b6d469c4cccd5
TF-A supports reading input data from UART interfaces. This opens up
an attack vector for arbitrary data to be injected into TF-A, which is
not covered in the threat model right now.
Fill this gap by:
- Updating the data flow diagrams. Data may flow from the UART into
TF-A (and not only the other way around).
- Documenting the threats inherent to reading untrusted data from a
UART.
Change-Id: I508da5d2f7ad5d20717b958d76ab9337c5eca50f
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Fixed internal links refrenced inside tfa/docs.
Followed https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#ref-role
for instrustion on how to link sections within other documents.
Signed-off-by: Thaddeus Serna <thaddeus.gonzalez-serna@arm.com>
Change-Id: I8e7c090d98951b1e3d393ab5b1d6bcdaa1865c6f
The generic threat model used to list threats in no particular order.
Reorganize threats so that they are grouped by mitigating entity. For
example, threats mitigated by the boot firmware (i.e. BL1 and BL2) are
now clubbed together, ditto for those mitigated by the runtime EL3
firmware. Note that some generic threats apply to all firmware images
so these get grouped in their own section as well.
The motivations for this refactoring are the following:
- Clarify the scope of the threats.
In particular, as the boot firmware is typically transient, threats
applying to those images can only be exploited during a short
period of time before the runtime firmware starts.
A note has been added to this effect.
- Helping developers implement mitigations in the right place.
- Some vendors have their own solution for booting their device and
only leverage the runtime firmware from the TF-A project. Thus,
they are not interested in the threat model of TF-A's boot
firmware. Isolating the latter in a specific section helps them
focus on what is important for them.
To avoid unnecessary churn, the threats ids have been kept the same.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Id8616fd0e4b37cd400b1ad3372beb3455234d4dc
The fact that RME is out of the generic threat model's scope is just
another assumption we make about the target of evaluation so mention
it there.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I839ec5427f36b085148338030e8b1b85191d4245
TF-A currently does not have any TPM2 driver for extending
measurements into a discrete TPM chip. In TPM-based attestation
scheme, measurements are just stored into a TCG-compatible event
log buffer in secure memory.
In light of the fact that Event Log measurements are taken by BL1 and
BL2, we need to trust these components to store genuine measurements,
and the Generic Threat Model always mitigates against attacks on these
components, therefore, there is no explicit document for the Measured
Boot threat model at this time is needed.
Change-Id: I41b037b2f5956d327b53cd834345e5aefdcfb5ef
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
There were some late comments to the prior change (18635) which are
address in this commit. There was also an invalid return value check
which was changed and the wrong result was being returned via the SMC
call for loading OP-TEE which is now fixed.
Signed-off-by: Jeffrey Kardatzke <jkardatzke@google.com>
Change-Id: I883ddf966662549a3ef9c801a2d4f47709422332
This adds the ability to load the OP-TEE image via an SMC called from
non-secure userspace rather than loading it during boot. This should
only be utilized on platforms that can ensure security is maintained up
until the point the SMC is invoked as it breaks the normal barrier
between the secure and non-secure world.
Signed-off-by: Jeffrey Kardatzke <jkardatzke@google.com>
Change-Id: I21cfa9699617c493fa4190f01d1cbb714e7449cc
Adding a new threat which is about leaving
sensitive information in internal buffers
which could be stolen by an attacker.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I737e802c0adc9b00c89a0e21779745c51afb4b17
- Cite crash reports as an example of sensitive
information. Previously, it might have sounded like this was the
focus of the threat.
- Warn about logging high-precision timing information, as well as
conditionally logging (potentially nonsensitive) information
depending on sensitive information.
Change-Id: I33232dcb1e4b5c81efd4cd621b24ab5ac7b58685
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
For each threat, we now separate:
- how to mitigate against it;
- whether TF-A currently implements these mitigations.
A new "Mitigations implemented?" box is added to each threat to
provide the implementation status. For threats that are partially
mitigated from platform code, the original text is improved to make
these expectations clearer. The hope is that platform integrators will
have an easier time identifying what they need to carefully implement
in order to follow the security recommendations from the threat model.
Change-Id: I8473d75946daf6c91a0e15e61758c183603e195b
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Add an explicit note that measured boot is out of scope of the threat
model. For example, we have no threat related to the secure
management of measurements, nor do we list its security benefits
(e.g. in terms of repudiation).
This might be a future improvement to the threat model but for now
just acknowledge it is not considered.
Change-Id: I2fb799a2ef0951aa681a755a948bd2b67415d156
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
The threat description was repeating the threat title.
Change-Id: I67de2c0aab6e86bf33eb91e7562e075fcb76259b
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Reword the description of threat #9 to make it more future-proof for
Arm CCA. By avoiding specific references to secure or non-secure
contexts, in favour of "worlds" and "security contexts", we make the
description equally applicable to 2-world and 4-world architectures.
Note that there are other threats that would benefit from such a
similar revamp but this is out of scope of this patch.
Also list malicious secure world code as a potential threat
agent. This seems to be an oversight in the first version of the
threat model (i.e. this change is not related to Arm CCA).
Change-Id: Id8c8424b0a801104c4f3dc70e344ee702d2b259a
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
By nature, experimental features are incomplete pieces of work,
sometimes going under rapid change. Typically, the threat model
implications have not been fully considered yet.
Change-Id: Ice8d4273a789558e912f82cde592da4747b37fdf
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
- Add empty lines after titles.
- Reduce number of highlighting characters to fit title length.
- Remove most ``monospaced text``.
I think most of it looked weird in the rendered HTML version and
it had no obvious meaning.
Change-Id: I5f746a3de035d8ac59eec0af491c187bfe86dad7
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Threat model for the current, BL1-only R-class support.
Signed-off-by: Gary Morrison <gary.morrison@arm.com>
Change-Id: I8479d5cb30f3cf3919281cc8dc1f21cada9511e0
This patch expands the RME documentation with description of TF-A
changes for RME. It also modifies some other parts of TF-A documentation
to account for RME changes.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I9e6feeee235f0ba4b767d239f15840f1e0c540bb
This is the first release of the public Trusted
Firmware A class threat model. This release
provides the baseline for future updates to be
applied as required by developments to the
TF-A code base.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I3c9aadc46196837679f0b1377bec9ed4fc42ff11
Manish V Badarkhe
laurenw-arm
Sandrine Bailleux
Thaddeus Serna
Jeffrey Kardatzke
Tamas Ban
Gary Morrison
Zelalem Aweke
Olivier Deprez