| /trusted-firmware-m-3.6.0/docs/doxygen/ |
| D | Doxyfile.in | 10 # This file describes the settings to be used by the documentation system
44 # The PROJECT_NUMBER tag can be used to enter a project or revision number. This
59 # the logo to the output directory.
63 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
65 # entered, it will be relative to the location where doxygen was started. If
70 # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
80 # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
81 # characters to appear in the names of generated files. If set to NO, non-ASCII
88 # The OUTPUT_LANGUAGE tag is used to specify the language in which all
90 # information to generate all constant output in the proper language.
[all …]
|
| /trusted-firmware-m-3.6.0/docs/design_docs/software/ |
| D | tfm_cooperative_scheduling_rules.rst | 13 TF-M enabled system need to be able to handle asynchronous events (interrupts)
14 regardless of current security state of the PE, and that may lead to scheduling
24 3. Reduce critical sections on the secure side to not block interrupts
26 4. Scalability to allow simplification/reduction of overheads to scale down the
50 - A NSPE exception handler returns from NSPE to pre-empted SPE context
51 - A SPE exception handler returns from SPE to pre-empted NSPE context
57 In order to maintain the call stack integrity across NSPE and SPE, following
63 1. **The NSPE exception handler is allowed to trigger a NSPE context switch**
77 This is to ensures integrity of the call stack when SPE is ready to return a
87 2. **The SPE interrupt handler is allowed to trigger a SPE context switch**
[all …]
|
| D | tfm_code_generation_with_jinja2.rst | 13 Some of the files in TF-M are generated from template files. The files to be
17 partition information from the partition manifests. The manifests to be used for
24 ``tools/tfm_parse_manifest_list.py`` Python script is used to generate files
25 from the templates. This script calls the ``tools/generate_from_template.py`` to
26 parse the template files, and uses ``tools/keyword_substitution.py`` to
33 The proposal is to eliminate the template parser and substituter scripts, and
35 ``tools/tfm_parse_manifest_list.py`` to do the substitution.
42 - ``tools/tfm_parse_manifest_list.py`` have to be modified to call the Jinja2
44 library is very similar to the one required by the current scripts.
45 - template files needs to be rewritten to the Jinja syntax: The control
[all …]
|
| D | code_sharing.rst | 13 it is often challenging to fit bigger projects in the available memory. The PSA
14 specifications require a device to both have a secure boot process in place at
15 device boot-up time, and to have a partition in the SPE which provides
20 mbed-crypto library to implement these requirements. During the build process,
22 bootloader requires less functionality) and then linked to the corresponding
32 which might need to use TF-M Profile Small anyway.
40 dynamic loading functionality. One major challenge to be solved in the Cortex-M
41 space is how to share code between independently linked XIP applications that
42 are tied to a certain memory address range to be executable and have absolute
51 the exclusive user. No attention needs to be paid as to where global data is
[all …]
|
| D | hardware_abstraction_layer.rst | 14 operations on the :term:`SPE` side and provides a set of APIs to the upper
16 The :term:`HAL` aims to cover the platform different aspects whereas common
20 it may not be possible to generalize implementations because lots of information
21 is only known to platforms.
22 It is more efficient to define a :term:`HAL` API for those architectural
27 :term:`TF-M` :term:`HAL` tries to reference :term:`TBSA-M` recommendations in
33 :term:`TF-M` :term:`HAL` is designed to simplify the integration efforts on
36 :term:`TF-M` :term:`HAL` is designed to make it easy to use the hardware and
37 develop the :term:`SPM` and :term:`RoT Service` which need to access the
40 :term:`TF-M` :term:`HAL` is designed to make the structure clearer and let the
[all …]
|
| /trusted-firmware-m-3.6.0/docs/integration_guide/ |
| D | index.rst | 4 The purpose of this document is to provide a guide on how to integrate TF-M
13 OS migration to Armv8-M <os_migration_guide_armv8m.rst>
25 How to build TF-M
30 How to export files for building non-secure applications
35 How to add a new platform
38 :doc:`Porting TF-M to a New Hardware </integration_guide/platform/porting_tfm_to_a_new_hardware>`
39 contains guidance on how to add a new platform.
42 How to integrate another OS
45 OS migration to Armv8-M platforms
47 To work with TF-M on Armv8-M platforms, the OS needs to support the Armv8-M
[all …]
|
| D | os_migration_guide_armv8m.rst | 2 Generic OS migration from Armv7-M to Armv8-M architecture
4 The purpose of this document is to list a set of requirements needed for
5 migrating a generic OS kernel running on Armv7-M to the Armv8-M architecture.
11 suggested to put specific code targeted to the Non Secure build under a
13 this case needs to be amended accordingly to support this new switch.
15 needs to be initialized and properly handled during thread context switch
18 value used in Handler mode transitions needs to be differentiated between
|
| D | tfm_secure_irq_integration_guide.rst | 9 This document describes how to enable an interrupt in TF-M. The target audiences
28 Partition Thread to have further data processing.
34 to scheduling.
40 The SLIH is deferred and subject to scheduling but all Secure Partition APIs are
43 Both the FLIH and the SLIH can be used by Secure Partitions which conform to
47 to Firmware Framework v1.0.
49 Please refer to chapter 6.2 of FF-M v1.1 [1]_ for more details on the interrupt
56 To enable an interrupt, you need to do the following:
58 - Binding the interrupt to a Secure Partition.
59 - Granting the Secure Partition access permissions to the device of the
[all …]
|
| /trusted-firmware-m-3.6.0/docs/security/security_advisories/ |
| D | stack_seal_vulnerability.rst | 5 | Title | NS world may cause the CPU to perform an unexpected return |
6 | | operation due to unsealed stacks. |
12 | Versions | All versions up to and including TF-M v1.1 |
29 When the Non-Secure world returns to Secure after a callback (FNC_RETURN) or
34 or EXC_RETURN and causes the PE to pop from the unexpected stack. Please
35 refer to `ARMv8-M Secure stack sealing advisory notice`_ for more
38 To prevent such an attack, the architecture expects the secure software to
42 Both the MSP_S and the PSP_S stacks need to be sealed to mitigate stack
52 PSP_S and then switches to MSP_S as part of SPM scheduling. The MSP_S is fully
56 partition execution using PSP_S switches to non-secure world due to a
[all …]
|
| /trusted-firmware-m-3.6.0/docs/design_docs/services/ |
| D | tfm_its_service.rst | 18 which is trusted to provide data confidentiality and authenticity. This
20 allows larger data sets to be stored securely in external flash, with the option
21 for encryption, authentication and rollback protection to protect the
32 The proposal is to implement the *PSA Internal Trusted Storage API* with the
33 *TF-M Internal Trusted Storage service*. It can be abbreviated to *TF-M ITS
34 service* in general and to ``its`` in code. This name has the advantage of
37 If this name is adopted, then it may make sense to rename the *Secure Storage
38 service* to the *Protected Storage service* in the future to match. Then "secure
39 storage" could refer to the two services as a collective.
42 a separate partition to Protected Storage, for a couple of reasons:
[all …]
|
| D | ps_key_management.rst | 11 The PSA Protected Storage API requires confidentiality for external storage to
20 128 bits of entropy (and a 128 bit data size), and be accessible only to Trusted
26 derivation function (KDF) to derive a storage key from the HUK, by referring to
28 volatile memory private to the Crypto partition, or it could remain inside a
29 secure element. Either way it will not be returned to PS.
31 For each call to the PSA Protected Storage APIs, PS will make requests to the
32 Crypto service to perform AEAD encryption and/or decryption operations using the
35 At no point will PS access the key material itself, only referring to the HUK
40 PS will make key derivation requests to the Crypto service with calls to the
41 PSA Crypto APIs. In order to derive the storage key, the following calls are
[all …]
|
| /trusted-firmware-m-3.6.0/docs/design_docs/ |
| D | tfm_physical_attack_mitigation.rst | 32 The goal of physical attacks is to alter the expected behavior of a circuit.
33 This can be achieved by changing the device's normal operating conditions to
37 and the attacker could gain access to the entire device. There is a wide variety
44 current through a small coil close to the chip surface, no physical contact
50 products to perform such attacks. Furthermore, they are shipped with a scripting
74 - A few instructions are skipped. This can lead to taking different branch
94 resistant to fault injection attacks. These can make it harder to perform a
96 content. The device maker needs to consider what level of physical attack is in
105 protection against physical attacks. The best of what is to achievable to harden
106 the system to increase the cost of a successful attack (in terms of time and
[all …]
|
| D | tfm_builtin_keys.rst | 16 keys for usage which are bound to the device instead of being owned by a
18 processing environment, the platform must provide a function to load these keys
20 location or subsystem. These keys are henceforth referred to as "builtin keys",
21 and might include (but are not limited to) the following:
26 The ``tfm_builtin_key_loader`` component implements a mechanism to discover
27 those keys and make them available to the PSA Crypto APIs for usage. Note that
29 processing environment, a full opaque driver [1]_ must be used to be able to use
35 volatile key, which requires some key-loading logic to be implemented by that
39 effort to load (and duplicate) the keys per each user, or require a dedicated
42 ``tfm_builtin_key_loader`` driver is to provide a uniform interface to use the
[all …]
|
| /trusted-firmware-m-3.6.0/lib/ext/cryptocell-312-runtime/codesafe/src/psa_driver_api/ |
| D | psa_driver_api_design.rst | 5 This document describes the high level design of the driver interface to the
7 as ``CC-3xx`` to indicate that it should be generic enough to easily support
17 The PSA Cryptoprocessor Driver interface describes a way to uniformly interface
18 a compliant PSA Crypto implementation to a cryptographic accelerator, that can
21 which is able to store keys in a separate, protected domain from the rest of
24 Due to the nature of the CC-312 processor, the natural choice is to implement
27 to provide support for a dedicated key management subsystem or add support for
29 interfaces which are specific to an _opaque_ driver as described by the
41 crypto core to call functionalities of the driver, and a set of `Internal APIs`_,
42 functions which are meant to be called by other modules of the driver, for
[all …]
|
| /trusted-firmware-m-3.6.0/docs/design_docs/dual-cpu/ |
| D | tfm_multi_core_access_check.rst | 14 permission to read or write the target memory region.
41 - Memory region is valid according to system settings
43 - Secure services should not directly access non-secure memory. According to PSA
44 Firmware Framework, Secure services should call Secure Partition APIs to ask
45 TF-M SPM to fetch non-secure input/output buffer for them.
51 - Memory region is valid according to system settings
53 - Secure services should not directly access non-secure memory. According to PSA
54 Firmware Framework, Secure services should call Secure Partition APIs to ask
55 TF-M SPM to fetch non-secure input/outputs buffer for them.
59 The check policy in Isolation Level 3 will be defined according to TF-M future
[all …]
|
| D | booting_a_dual_core_system.rst | 12 There are many possibly ways to design a dual core system. Some important
15 - Which core has access to which areas of Flash?
17 - It is possible that the secure core has no access to the Flash from which
23 does it jump to a set address, …?
32 In an effort to make the problem manageable, as well as to provide a system
33 with good performance, that is flexible enough to work for a variety of dual
37 access to the Flash that the non-secure core will boot from
39 - This keeps the boot flow as close as possible to the single core design,
44 up hardware protection to (potentially) start the non-secure core running
46 - This is the earliest point at which it is safe to allow the non-secure
[all …]
|
| /trusted-firmware-m-3.6.0/platform/ext/target/arm/corstone1000/ |
| D | config.cmake | 10 set(BL1 ON CACHE BOOL "Whether to build BL1")
11 set(PLATFORM_DEFAULT_BL1 ON CACHE STRING "Whether to use default BL1 or pl…
12 set(PLATFORM_DEFAULT_OTP OFF CACHE BOOL "Use trusted on-chip flash to imp…
18 …{CMAKE_CURRENT_LIST_DIR}/bl1/bl1_1_shared_symbols.txt CACHE FILEPATH "Path to list of symbols that…
23 set(BL2 ON CACHE BOOL "Whether to build BL2")
25 set(DEFAULT_MCUBOOT_FLASH_MAP OFF CACHE BOOL "Whether to use the default flash…
27 … "1" CACHE STRING "Security counter for S image. auto sets it to IMAGE_VERSION_S")
29 set(MCUBOOT_IMAGE_NUMBER 2 CACHE STRING "Whether to combine S and NS into…
32 set(TFM_PLAT_SPECIFIC_MULTI_CORE_COMM ON CACHE BOOL "Whether to use a platform specif…
34 set(CRYPTO_HW_ACCELERATOR ON CACHE BOOL "Whether to enable the crypto ha…
[all …]
|
| /trusted-firmware-m-3.6.0/docs/contributing/ |
| D | contributing_process.rst | 4 Contributions to the TF-M project need to follow the process below.
10 - It is recommended to subscribe to `TF-M mailing list <mailing_list_>`_
12 - Refer to the `Roadmap
13 <https://developer.trustedfirmware.org/w/tf_m/planning>`_ or send a mail to
14 the `TF-M mailing list <mailing_list_>`_ to get the latest status and plan of
17 to propose your design.
18 - Follow guidelines below to prepare the patch:
25 - Make your changes in logical chunks to help reviewers. Each commit should
29 to update documentation in ``docs`` folder if needed.
30 - Test your changes and add details to the commit description.
[all …]
|
| /trusted-firmware-m-3.6.0/docs/design_docs/booting/ |
| D | secure_boot_rollback_protection.rst | 11 The goal of anti-rollback protection is to prevent downgrading of the device to
12 an older version of its software, which has been deprecated due to security
26 Boot loader is responsible to authenticate the new image according to the
31 charge to do the necessary steps (load to execute address, etc.) to enable the
32 new image to be executed. During the validation process the image and the
39 - Image header: Prepended to the beginning of the image.
41 - TLV section: Appended to the end of the image. It is not integrity protected:
60 The aim of a security counter is to have an independent (from the image version)
61 counter in the image manifest to ensure anti-rollback protection. During
64 device then it is not allowed to go back to earlier versions. It is beneficial
[all …]
|
| /trusted-firmware-m-3.6.0/bl2/ext/mcuboot/ |
| D | mcuboot_default_config.cmake | 10 set(TEST_BL2 OFF CACHE BOOL "Whether to build bl2 tests")
12 set(DEFAULT_MCUBOOT_SECURITY_COUNTERS ON CACHE BOOL "Whether to use the default sec…
13 set(DEFAULT_MCUBOOT_FLASH_MAP ON CACHE BOOL "Whether to use the default fla…
18 set(MCUBOOT_IMAGE_NUMBER 2 CACHE STRING "Whether to combine S and NS in…
19 set(MCUBOOT_EXECUTION_SLOT 1 CACHE STRING "Slot from which to execute the…
20 set(MCUBOOT_LOG_LEVEL "INFO" CACHE STRING "Level of logging to use for MC…
21 set(MCUBOOT_HW_KEY ON CACHE BOOL "Whether to embed the entire pu…
26 set(MCUBOOT_CONFIRM_IMAGE OFF CACHE BOOL "Whether to confirm the image i…
29 # platforms to choose a specific upgrade strategy for images. These certain
30 # configurations will be used to facilitate the later validation.
[all …]
|
| /trusted-firmware-m-3.6.0/platform/ext/target/cypress/psoc64/libs/core-lib/ |
| D | EULA | 7 …tation, including any upgrades, updates, bug fixes or modified versions provided to you by Cypress.
13 …Development Tools" means software that is intended to be installed on a personal computer and used…
19 …e that executes on a device other than a Cypress hardware product in order to program, control, or…
21 …nformation file (.inf file) created by the Software to allow a Microsoft Windows operating system …
23 …icense. Subject to the terms and conditions of this Agreement, Cypress Semiconductor Corporation …
25 …a. to use the Development Tools in object code form solely for the purpose of creating Firmware, D…
27 … Code form, to copy, modify, and compile the Firmware Source Code to create Firmware for execution…
29 …to copy, modify, and compile the Driver Source Code to create one or more Drivers to enable the us…
31 …to copy, modify, and compile the Host Application Source Code to create one or more Host Applicati…
33 e. to freely distribute any inf File.
[all …]
|
| /trusted-firmware-m-3.6.0/docs/building/ |
| D | tests_build_instruction.rst | 10 and includes it to SPE binary.
11 Also, test configurations should be passed to SPE build to include building Secure Tests.
13 To hide these complexities to developers, TF-M implements a wrapper CMake in **tf-m-tests**
14 repository [1]_ to build the SPE for testing rather than building it from the TF-M repository.
16 The recommended tf-m-tests repo commit to verify TF-M can be found at
19 You need to download it manually before building any tests with the following commands:
29 please refer to the documentation in **tf-m-tests** repository (to be added).
31 It is recommended to build both SPE and NSPE from that folder.
40 -DTFM_TOOLCHAIN_FILE=<Absolute path to>/toolchain_ARMCLANG.cmake \
44 cmake -S . -B build_test -DCONFIG_SPE_PATH=<Absolute path to>/build_spe/api_ns
[all …]
|
| /trusted-firmware-m-3.6.0/platform/ext/target/arm/rss/kronos/ |
| D | config.cmake | 13 …RAS_REPO_PATH "" CACHE PATH "Path to tf-m-extras repo (or DOWNLOAD to fet…
14 set(TFM_EXTRAS_REPO_VERSION "" CACHE STRING "The version of tf-m-extras to use")
20 …_EXTRA_CONFIG_PATH "" CACHE PATH "Config to append to standard Mbed Crypto config, used by pla…
22 …t/tfm_manifest_list.yaml" CACHE PATH "Config to append to standard Mbed Crypto config, used by pla…
|
| /trusted-firmware-m-3.6.0/docs/platform/arm/rss/ |
| D | rss_provisioning.rst | 7 The LifeCycle Manager (LCM) controls access to the RSS OTP, and includes a
10 CryptoCell-3XX series accelerators, and will be familiar to those who have
15 provisioning must be to set the LCM to either test-chip mode "TCI" or
16 production-chip mode "PCI". In TCI mode the RTL key is masked to avoid
17 disclosure, several OTP fields are changed from write-only to read-write, to aid
20 (which it is by default) then the chip will be set to TCI mode. If this option
21 is not enabled, execution will pause to allow the setting to be set by a
29 VM0. This bundle contains the keys and also code to perform the provisioning
30 such as a driver for the LCM, and a function to randomly generate the HUK via
33 SRAMs), and allows access to the RTL key by exporting it to the KMU, though in
[all …]
|
| /trusted-firmware-m-3.6.0/config/ |
| D | config_base.cmake | 13 … ${CMAKE_SOURCE_DIR}/toolchain_GNUARM.cmake CACHE FILEPATH "Path to TFM compiler toolcha…
14 set(TFM_PLATFORM "" CACHE STRING "Platform to build TF-M for. Mu…
30 … CACHE BOOL "Add debug symbols. Note that setting CMAKE_BUILD_TYPE to Debug or RelWithDebI…
31 set(TFM_CODE_COVERAGE OFF CACHE BOOL "Whether to build the binary fo…
36 …O_PATH "DOWNLOAD" CACHE PATH "Path to Mbed Crypto (or DOWNLOAD to fetch …
38 set(MBEDCRYPTO_VERSION "mbedtls-3.5.0" CACHE STRING "The version of Mbed Crypto to…
39 … "https://github.com/Mbed-TLS/mbedtls.git" CACHE STRING "The URL (or path) to retrieve MbedTLS fro…
41 …_PATH "DOWNLOAD" CACHE PATH "Path to MCUboot (or DOWNLOAD to fetch au…
42 set(MCUBOOT_VERSION "v2.0.0" CACHE STRING "The version of MCUboot to use")
44 set(PLATFORM_PSA_ADAC_SECURE_DEBUG FALSE CACHE BOOL "Whether to use psa-adac secure…
[all …]
|
