Thanks, everyone. This is all very helpful.
I see that docs/platform/arm/rss/readme.rst just refers to the generic build instructions. I wonder if it might make sense to add a note about the tf-m-extras repo there?
Chris
From: Jamie Fox via TF-M tf-m@lists.trustedfirmware.org Sent: September 7, 2022 10:29 AM To: Brand Chris (CSCA CSS ICW SW PSW 1) Chris.Brand@infineon.com; tf-m@lists.trustedfirmware.org Cc: Maulik Patel Maulik.Patel@arm.com Subject: [TF-M] Re: Status of RSS platform?
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Chris,
I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions.
Currently RSS only receives messages from other processors that are serialized and sent in-band over the MHUs, so no pointers to check in this case. The only mem checks are within the RSS core, which are the same as other Armv8-M platforms (see platform/ext/target/arm/rss/tfm_hal_isolation.c).
But... we will add support for MHU messages containing pointers to shared memory in the other processors, but I think even then the current multi-core mem checks in tfm_multi_core_mem_check.c are not a good fit for us, because:
1. It manually checks MPU regions, which isn't necessary on Armv8-M where we have the TT instruction for that. 2. The pointers RSS receives over the MHU are 64-bit addresses, which will be dynamically mapped into regions in RSS's 32-bit memory map. By the time SPM calls the mem check, it only has the 32-bit address, which isn't useful for checking access rights to the original address. 3. RSS can receive messages from multiple other endpoints each with their own MHU, so which addresses are permitted depends on which MHU the message was received. Again, this information is not available at the point the SPM makes the mem check, it's not enough to know the message came from "NS" because there's more than one "NS". I think 1 is easily solved by abstracting the arch from the multi-core implementation, and relevant for any Armv8-M multi-core platform. For 2 and 3, they are quite RSS-specific problems and, though it should be possible to recover the original address and sender inside the RSS implementation of the HAL, it would all be a bit circuitous. I think for us it makes more sense to check memory permissions in the MHU receiver code, at the point the address is extracted from the MHU message and before the SPM is called. See here for relevant patch in progress: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15949
Kind regards, Jamie
From: Maulik Patel via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 07 September 2022 09:46 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [TF-M] Re: Status of RSS platform?
Hi Chris,
RSS build requires new runtime Measured Boot Service. This service partition is not yet part of PSA specification and hence it resides in the tf-m-extras repository. (https://git.trustedfirmware.org/TF-M/tf-m-extras.git/)
For out of tree partition build, if you map the tf-m-extras repo and provideTFM_EXTRA_MANIFEST_LIST_FILES =<path_to_measured_boot_manifest_list.yaml> and TFM_EXTRA_PARTITION_PATHS=<path_to_measured_boot_partition> (example as below), then it should fix build issue.
-DTFM_EXTRA_MANIFEST_LIST_FILES=../../tf-m-extras/partitions/measured_boot/measured_boot_manifest_list.yaml -DTFM_EXTRA_PARTITION_PATHS=../../tf-m-extras/partitions/measured_boot
If the error persists, could you please send me the build options you are using and I'll look into this further.
Best Regards, Maulik
________________________________ From: tf-m-request@lists.trustedfirmware.orgmailto:tf-m-request@lists.trustedfirmware.org <tf-m-request@lists.trustedfirmware.orgmailto:tf-m-request@lists.trustedfirmware.org> Sent: Wednesday, September 7, 2022 1:00 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: TF-M Digest, Vol 47, Issue 7
Send TF-M mailing list submissions to tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request@lists.trustedfirmware.orgmailto:tf-m-request@lists.trustedfirmware.org
You can reach the person managing the list at tf-m-owner@lists.trustedfirmware.orgmailto:tf-m-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..."
Today's Topics:
1. Status of RSS platform? (Chris.Brand@infineon.commailto:Chris.Brand@infineon.com)
----------------------------------------------------------------------
Message: 1 Date: Tue, 6 Sep 2022 21:48:05 +0000 From: <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com> Subject: [TF-M] Status of RSS platform? To: <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Message-ID: <2441d128df93483abc1da39c38e89885@infineon.commailto:2441d128df93483abc1da39c38e89885@infineon.com> Content-Type: multipart/alternative; boundary="_000_2441d128df93483abc1da39c38e89885infineoncom_"
Hi,
I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code).
I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions.
Thanks,
Chris Brand
Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand@infineon.com<mailto:Chris.Brand@infineon.commailto:Chris.Brand@infineon.com%3cmailto:Chris.Brand@infineon.com>
International Place 13700 V6V 2X8 Richmond Canada
www.infineon.com<www.cypress.comhttp://www.cypress.com> www.cypress.comhttp://www.cypress.com Discoverieshttp://www.infineon.com/discoveries Facebookhttp://www.facebook.com/infineon Twitterhttp://www.twitter.com/Infineon LinkedInhttp://www.linkedin.com/company/infineon-technologies
Part of your life. Part of tomorrow.
NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.