Searched refs:from (Results 1 – 25 of 156) sorted by relevance
1234567
| /trusted-firmware-m-3.4.0/docs/platform/stm/common/stm32u5xx/ |
| D | readme.rst | 14 Content from https://github.com/STMicroelectronics/stm32u5xx_hal_driver.git
17 Content from https://github.com/STMicroelectronics/cmsis_device_u5.git
20 …stm32l5xx bl2 code specific from https://github.com/STMicroelectronics/STM32CubeU5.git (Projects/B…
23 …stm32l5xx Secure porting adaptation from https://github.com/STMicroelectronics/STM32CubeU5.git (Pr…
26 …Adaptation for stm32 board using stm32l5xx soc from https://github.com/STMicroelectronics/STM32Cub…
47 The virtual com port from STLINK is used for TFM log and serial port configuration should be:
|
| /trusted-firmware-m-3.4.0/docs/platform/stm/common/stm32l5xx/ |
| D | readme.rst | 15 Content from https://github.com/STMicroelectronics/stm32l5xx_hal_driver.git
18 Content from https://github.com/STMicroelectronics/cmsis_device_l5.git
21 …stm32l5xx bl2 code specific from https://github.com/STMicroelectronics/STM32CubeL5.git (Projects/S…
24 …stm32l5xx Secure porting adaptation from https://github.com/STMicroelectronics/STM32CubeL5.git (Pr…
27 …Adaptation and tools specific to stm32 board using stm32l5xx soc from https://github.com/STMicroel…
53 The virtual com port from STLINK is used for TFM log and serial port configuration should be:
|
| /trusted-firmware-m-3.4.0/docs/configuration/ |
| D | build_configuration.rst | 16 3. If TEST_PSA_TEST is set, then PSA API test related config is applied from
18 4. If it exists, CMAKE_BUILD_TYPE specific config is applied from
20 5. Target specific config from ``platform/ext/target/<target_platform>/config.cmake``
24 7. If it exists, TFM Profile specific config is applied from
29 config from ``${TFM_TEST_REPO_PATH}/test/config/set_config.cmake`` and
|
| /trusted-firmware-m-3.4.0/docs/technical_references/design_docs/ |
| D | tfm_cooperative_scheduling_rules.rst | 44 - A NSPE interrupt take control into NSPE from SPE
45 - A SPE interrupt takes control into SPE from NSPE
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
53 - SPE returns a call from NSPE
55 - NSPE returns a call from SPE (not covered in current design)
78 previous function call from NSPE.
101 In this case SPM is not yet aware of the NSPE context switch, from SPM's
136 Rules for Function Return from SPE to NSPE with result
149 or a context restore via 'return to SPE from NSPE'. As opposed to a SPE
[all …]
|
| D | tfm_code_generation_with_jinja2.rst | 10 Generating files from templates in TF-M
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
25 from the templates. This script calls the ``tools/generate_from_template.py`` to
27 substitute the keychains with actual values from the manifest files.
34 call the Jinja2 template engine library from
|
| D | ff_isolation.rst | 19 This chapter describes the definitions from ``FF-M`` and analyzes
29 - L1.1 NPSE needs protection from nobody.
30 - L1.2 SPE needs protection from NSPE.
34 - L2.1 NPSE needs protection from nobody.
35 - L2.2 Application Root of Trust (ARoT) needs protection from NSPE.
36 - L2.3 PSA Root of Trust (PRoT) needs protection from NSPE and ARoT.
40 - L3.1 NPSE needs protection from nobody.
41 - L3.2 Secure Partition needs protection from NSPE and other Secure Partitions.
42 - L3.3 PSA Root of Trust (RoT) domain needs protection from NSPE and all Secure
62 The essence of isolation is to protect the assets of one protection domain from
[all …]
|
| D | ps_key_management.rst | 26 derivation function (KDF) to derive a storage key from the HUK, by referring to
57 /* Create the storage key from the key derivation operation */
69 material and different to the label used in any other derivation from the
70 same input key. It prevents two different contexts from deriving the same
71 output key from the same input key.
95 The Crypto service derives a platform key from the HUK, using the partition ID
98 from deriving from the HUK except that other partitions cannot derive the
|
| D | tfm_its_service.rst | 71 ``secure_fw/ns_callable/tfm_veneers.c`` - ITS veneers (auto-generated from
119 but with the addition of a ``client_id`` parameter, which will be passed from
131 The ITS filesystem will be copied and modified from the SST filesystem. The
132 modifications required will be to rename symbols from ``sst`` to ``its`` and to
135 and using common error codes from ``psa/error.h``).
146 The flash layer will be copied from SST, and modified to direct writes to the
169 SST uses the object table to do the mapping from client ID, UID pairs to file
176 - Keep a simplified version of the SST object table that just maps from
207 from being modified or deleted after it is set for the first time.
253 Storage to use. This, for example, prevents Protected Storage from doing partial
[all …]
|
| D | tfm_secure_boot.rst | 15 executed from ROM or such part of flash memory which supports write
30 By default, the MCUboot project from
39 Bootloader is started when CPU is released from reset. It runs in secure mode.
128 upgrade. In this case the active firmware is always executed from the primary
136 can be executed from either memory slot, but new firmware must be linked to the
145 the content of the secondary slot, before starting the new image from the
160 and the secondary slot will be swapped, before starting the new image from the
162 swapping. Update mark from the secondary slot is removed when the swapping is
184 One of them is linked to be executed from the primary slot memory region and the
185 other from the secondary slot. The firmware upgrade client, which downloads the
[all …]
|
| /trusted-firmware-m-3.4.0/docs/security/security_advisories/ |
| D | fwu_write_vulnerability.rst | 17 | Impact | In IPC model, the caller of ``psa_fwu_write()`` from SPE |
24 | | Staff Software Engineer from Arm Ltd. |
57 is greater than ``1024``, then the memory space starting from the address
64 In IPC model, the caller of ``psa_fwu_write()`` from SPE or NSPE can overwrite
65 the memory space in RAM. The overwritten memory space ranges from the address
|
| D | stack_seal_vulnerability.rst | 31 address and RET_PSR from the respective secure stack. The hardware performs a
34 or EXC_RETURN and causes the PE to pop from the unexpected stack. Please
51 All requests coming in from the Non-Secure world uses ARM_LIB_STACK as the
60 the return PC and PSR from the memory just above MSP_S stack (stack grows
61 from higher to lower address).
97 Overall, from analysis of upstream TF-M implementation, the severity of this
98 vulnerability is low, given that the values popped out from secure stack
99 (either via underflow of MSP_S or from top of MSP_S stack in de-privileged
|
| D | svc_caller_sp_fetching_vulnerability.rst | 5 | Title | Invoking Secure functions from handler mode may cause TF-M |
24 | | Senior SW Engineer from Nordic Semiconductor |
33 handles requests from SPE and NSPE in a unified SVC handler. The TF-M SVC
50 the transition from non-secure state to secure state via the successful SG.
58 should also prevent callers in non-secure `Handler mode` from calling TF-M
91 could be fetched from the incorrect stack and what operation the fetched SVC
94 - A memory access fault when fetching the SVC number from memory. This fault
114 Overall, from the analysis of upstream TF-M implementation, the severity of
|
| /trusted-firmware-m-3.4.0/docs/integration_guide/platform/ |
| D | platform_ext_folder.rst | 5 This folder has code that has been imported from other projects. This means the
43 This folder contains core and compiler specific header files imported from the
81 the directory path from the ``target`` directory to its ``CMakeLists.txt`` file
132 to select a particular set of code from a vendor SDK.
190 - ``FLASH_AREA_BL2_OFFSET`` - Defines the offset from the flash base address
193 - ``FLASH_AREA_SCRATCH_OFFSET`` - Defines the offset from the flash base
205 - ``FLASH_AREA_0_OFFSET`` - Defines the offset from the flash base address
209 - ``FLASH_AREA_2_OFFSET`` - Defines the offset from the flash base address
217 - ``FLASH_AREA_0_OFFSET`` - Defines the offset from the flash base address
221 - ``FLASH_AREA_1_OFFSET`` - Defines the offset from the flash base address
[all …]
|
| /trusted-firmware-m-3.4.0/docs/platform/lairdconnectivity/bl5340_dvk_cpuapp/ |
| D | README.rst | 71 #. Download the appropriate package from the
80 The nRF Command-line Tools allow you to control your BL5340 module from the
88 path to be able to invoke it from anywhere.
100 Generate Intel hex files from the output binary (bin) files as follows:
113 * Flash the BL2 and the TF-M image binaries from the sample folder of your choice:
133 Generate Intel hex files from the output binary (bin) files as follows:
146 * Flash the BL2 and the TF-M image binaries from the sample folder of your choice:
|
| /trusted-firmware-m-3.4.0/docs/platform/cypress/psoc64/libs/core-lib/ |
| D | RELEASE.md | 17 * CY_GET_REG8: Reads the 8-bit value from the specified address
19 * CY_GET_REG16: Reads the 16-bit value from the specified address
21 * CY_GET_REG24: Reads the 24-bit value from the specified address
23 * CY_GET_REG32: Reads the 32-bit value from the specified register
54 * Migrated numerous utility & cross compiler macros from psoc6pdl into here
|
| D | README.md | 21 * `CY_GET_REG8`: Reads the 8-bit value from the specified address
23 * `CY_GET_REG16`: Reads the 16-bit value from the specified address
25 * `CY_GET_REG24`: Reads the 24-bit value from the specified address
27 * `CY_GET_REG32`: Reads the 32-bit value from the specified register
|
| /trusted-firmware-m-3.4.0/docs/technical_references/design_docs/dual-cpu/ |
| D | booting_a_dual_core_system.rst | 13 considerations from a boot perspective are:
17 - It is possible that the secure core has no access to the Flash from which
37 access to the Flash that the non-secure core will boot from
71 - All work related to the non-secure core will take place from a
102 - Called on the secure core from ``ns_agent_mailbox`` partition when it first
112 - Called on the secure core from ``ns_agent_mailbox`` partition after making the
125 - Called on the non-secure core from ``main()`` after the dual-core-specific
|
| D | mailbox_design_on_dual_core_system.rst | 69 replied from SPE, NSPE mailbox fetches the result and returns it to PSA Client
77 The SPE mailbox in TF-M receives PSA Client requests from NSPE mailbox. It
106 objects should be protected from NSPE accesses by system specific isolation.
120 request. Each slot serves a PSA Client call from non-secure task.
125 The mailbox reply structure is used to receive the PSA Client result from SPE.
131 A mailbox message contains the parameters of a PSA Client request from a
138 SPE mailbox will parse those parameters from the mailbox message.
141 from NSPE to SPE for processing in TF-M.
147 replied from SPE mailbox. Please refer to the structure definition in
159 PSA Client call parameters from non-secure memory to that slot and parse the
[all …]
|
| /trusted-firmware-m-3.4.0/docs/platform/arm/corstone1000/ |
| D | readme.rst | 16 is treated as non-secure from the Secure Enclave perspective.
64 This section can be used to test the secure enclave software indedendently from
74 - Download Corstone-1000 FVP from : `Arm Ecosystem FVPs`_
77 from tf-m-test along with platform specific tests are executed.
92 - Use the BL1 generated from the below commands to place it inside FPGA board SD Card.
93 - Use the cs1000.bin created from the below commands to place it inside FPGA board SD Card.
|
| /trusted-firmware-m-3.4.0/docs/platform/nordic_nrf/nrf9160dk_nrf9160/ |
| D | README.rst | 59 #. Download the appropriate package from the `J-Link Software and documentation pack`_ website
67 The nRF Command-line Tools allow you to control your nRF9160 device from the command line,
74 to be able to invoke it from anywhere.
86 Generate Intel hex files from the output binary (bin) files as follows:
99 * Flash the BL2 and TF-M image binaries from the sample folder of your choice:
|
| /trusted-firmware-m-3.4.0/docs/platform/arm/rss/ |
| D | readme.rst | 13 RSS initially boots from immutable code (BL1_1) in its internal ROM, before
15 MCUBoot BL2 boot stage is loaded from host system flash into RSS SRAM, where it
17 from host flash. BL2 is also responsible for loading initial boot code into
64 subsequent host image to be loaded at an offset of ``0x100000`` from the
102 the signed host images from the previous section. For each boot image, there is
|
| /trusted-firmware-m-3.4.0/docs/platform/nordic_nrf/nrf5340dk_nrf5340_cpuapp/ |
| D | README.rst | 66 #. Download the appropriate package from the `J-Link Software and documentation pack`_ website
74 The nRF Command-line Tools allow you to control your nRF5340 device from the command line,
81 to be able to invoke it from anywhere.
93 Generate Intel hex files from the output binary (bin) files as follows:
106 * Flash the BL2 and the TF-M image binaries from the sample folder of your choice:
|
| /trusted-firmware-m-3.4.0/bl2/ext/mcuboot/ |
| D | mcuboot_default_config.cmake | 19 set(MCUBOOT_EXECUTION_SLOT 1 CACHE STRING "Slot from which to execute the…
40 …OOL "Support initial state with empty primary slot and images installed from secondary slots")
45 # and KEY_NS will either have to be updated manually or removed from the cache.
46 # `cmake .. -UMCUBOOT_KEY_S -UMCUBOOT_KEY_NS`. Once removed from the cache it
|
| /trusted-firmware-m-3.4.0/platform/ext/target/lairdconnectivity/bl5340_dvk_cpuapp/ |
| D | config.cmake | 9 # Relative path to nordic platform files from scope of the lairdconnectivity/common/core folder
|
| /trusted-firmware-m-3.4.0/docs/releases/ |
| D | 1.4.0.rst | 15 - Decouple NS RTOS specific implementation from NS interface.
42 The following platforms have been removed from TF-M code base.
89 * - | NS interrupt masking prevents from executing PSA calls.
|
1234567
