Hi,
I'd like to propose presenting some of the work we've done around
"Confidential AI" with TF-M and Zephyr during the next TF Tech Forum call.
I think I'll probably need 30 minutes or so, and can take some questions
after time and agenda permitting.
If you're not familiar with the project, it's an attempt at trying to
determine how open standards and open source software (Zephyr, TF-M,
MCUBoot, etc.) can be used together in a practical, end-to-end security use
case ... in this case, running inference on sensor data in the secure
partition, and transmitting sensitive data from S to NS to the cloud.
Relevant repos are here, but of course I'll try to give a meaningful
overview of all of this during the call since the project has several
related components:
- https://github.com/Linaro/zephyr_confidential_ai
- https://github.com/Linaro/lite_bootstrap_server
Thanks and best regards,
Kevin Townsend
Tech Lead - LITE, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Hi,
Is it correct that CONFIG_TFM_FP_ARCH_ASM is 'empty string' when using FP_ARCH_FPV5_SP_D16? I'm wondering if it should be set to "FPv5-SP"
############################## FP Arch #########################################
config FP_ARCH_FPV5_D16
def_bool n
help
FPv5-D16
config FP_ARCH_FPV5_SP_D16
def_bool n
help
FPv5-SP-D16
config CONFIG_TFM_FP_ARCH
string
default "fpv5-d16" if FP_ARCH_FPV5_D16
default "fpv5-sp-d16" if FP_ARCH_FPV5_SP_D16
default ""
config CONFIG_TFM_FP_ARCH_ASM
string
default "FPv5_D16" if FP_ARCH_FPV5_D16
default ""
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello,
The changes made for the TF-M v1.8.0 are merged back to the master branch.
To allow that, Corstone-1000 platform was temporarily excluded from OpenCI tests because the platform changes in the release branch conflicted with changes in the master, made in parallel. The platform will be back under test immediately after the conflict resolution.
Corstone-1000 platform builds and runs correctly under v1.8.0 tag.
Thanks,
Anton
Hello,
I am pleased to announce the release of TF-M v1.8.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…>.
New major features are:
* TF-M eRPC Test framework 1 is integrated.
* TF-M builtin key loader integration is reworked.
* Improved crypto library abstraction from TF-M Crypto service.
* Kconfig system is enhanced and finalized.
* Switch to upstream QCBOR 2.
* Enable PSA Authenticated Debug Access Control (ADAC) 3 support on Musca-B1 platform.
* Support Floating-Point (FP) with Arm Compiler.
* FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly.
* MCUboot upgrade to v1.10.0.
* Mbed TLS upgrade to v3.4.0.
* Refine documentation restructure.
* It is optional to update copyright year in changes. Requirements of copyright note update is updated in Contributing Process.
Please check the release notes<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…> for more information.
The release branch changes will be ported to the main branch shortly.
Many thanks to everyone for contributing, reviewing and supporting this milestone.
Anton
Hello,
For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified.
Currently, there are several obvious places to be improved:
- Handlers in C have multiple-level function calling;
- There are a couple of checks in the handler routine that can be refined.
And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable.
The leading patches are here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644
Feel free to comment or reply in this thread.
Thanks.
/Ken
Hi,
We're making some adjustments for the SVC number assignments.
I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted.
Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode.
This is not convenient for adding new SVC because it's not intuitive to find a proper value range.
More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files.
So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC.
Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions.
With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values.
Thanks,
Kevin
Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage>
target_include_directories(tfm_psa_rot_partition_its
PRIVATE
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>
${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage
PUBLIC
# Required for ps_object_defs.h
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage
)
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello everyone,
I need to extend PSA Crypto API by adding a platform specific encryption algorithm/key attribute. For example a vendor specific algorithm named ABC must be added. So, I need that following macro must be included when psa/crypto.h is included.
#define PSA_ALG_ABC ((psa_algorithm_t) 0x08000123)
TF-M provides PSA Crypto interface through includes located in interface/include/psa/crypto*.h. It means that we need to extend TF-M by allowing platform to provide some platform specific crypto header that will be installed in interface folder and included by psa/crypto.h.
1. Is there any activity related to this problem?
2. I'm considering to create a new crypto_config.h that must be generated during build process and which can optionally provide a macro TFM_PLATFORM_CRYPTO_EXTRA. These macro will be used in psa/crypto.h to conditionally include crypto_platform.h - header provided by platform.
Thanks,
Roman.
Hi. We at Nordic are running the TF-M regression and PSA architecture tests on our boards, and we get occasional issues with test output because HW flow control is by default disabled in CMSIS.
To enable HW flow control in the TF-M we must change the call to the CMSIS UART driver.
I've created a change to allows the platform to set any non-default CMSIS configuration, such as HW flow control:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20374
I'd like to ask all platform maintainers to review this change.
This change must add another define to all supported platforms, the change itself should not cause any difference in actual behavior.
This can be used for other non-default UART configuration in other platforms as well.
-Joakim Andersson