Hi everyone,
While reading FWU service doc<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> I found that Components paragraph<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> contain table which says that tfm_bootloader_fwu_abstraction.h file is located in ./secure_fw/partitions/firmware_update/tfm_bootloader_fwu_abstraction.h , but it TF-M repo it is located in secure_fw\partitions\firmware_update\bootloader\tfm_bootloader_fwu_abstraction.h.
Minor thing, but still worth fixing.
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
I'm working on adding IARARM as a toolchain for the Musca S1 (and B1)
and I'm running into an issue where the NS image can not properly access
the UART.
The NS code loops trying to check the UART status @0x40102030, which
holds the value 0x301, as can be seen with the debugger and also from
the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume
there is some memory protection that gets incorrectly setup when I build
with the IAR toolchain, but I'm struggling to find where this gets
setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi George,
I'm wondering if that would add value. To my understanding, ITS was never
designed to be encrypted because of the way it's supposed to be set up.
(It's Internal Trusted Storage.) I believe best practice is to place it in a
"trusted" location, one that is ideally only accessible from Secure world,
and also ideally on-die. If you then restrict outside access to the internal
flash (JTAG, flash programmer ports,.), you're pretty golden, in that no
unauthorized party should be able to read from or write to the ITS.*
Let me know if I misunderstand anything about ITS or TrustZone, but that's
my view. Maybe I'm painting an idealized picture.
Greetings,
Fabian Schmidt
* at least short of a sophisticated physical attack or finding some loophole
in TrustZone.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vasilakis,
Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] Supporting encryption with ITS
Caution: EXT Email
Hey all,
Lately the requirement for an encrypted ITS solution is being asked from our
customers and I would like to have a discussion here on how we can design
this in a reasonable way. The first thought that came to my mind was to add
the functionality to the ITS flash-fs layer. This layer contains file
metadata in the its_file_meta_t structure and it should be possible to
expand this to include additional crypto metadata (conditionally). This
seems to be the less invasive change to me, even though it will introduce
some increased memory usage since supporting encryption will mean that we
cannot read the data in chunks anymore, we will have to use static buffers.
At the same time, I looked at the PS partition since I knew that it has
support for encryption. I believe that some core concepts of both solutions
have similarities even though the code is quite different. For example, a
file in ITS is similar to an object in PS and the (linear) list of file
metadata in ITS is similar to the concept of the object table in PS. So, I
think that it should be possible to design some generic-enough APIs that we
can use for both the ITS and PS. Even though this will require some major
refactoring in both partitions, it will decrease the code of these services
which will probably decrease maintenance later.
What are your thoughts on this?
Regards,
George
Hello,
Please be informed about the update v1.4.1 containing a hotfix for a vulnerability found in v1.4.0.
The vulnerability exists in Profile Small only so please update to v1.4.1 version if you are currently using TF-M v1.4.0 and Profile Small.
The detailed security advisory will be provided later.
Best regards,
Anton
Thank you both for the input!
Andrej, you are correct that right now PS == Encrypted ITS but my understanding of the spec tells me that this will not always be the case. They do refer to platforms that will use external storage for PS (even though they still require ITS even in this case indeed).
And just to clarify, I don't propose creating yet another ITS. The second thought that I had regarding the refactoring is mainly a common library that both ITS and PS can use for object handling.
Fabian, I also understand it similarly, the ITS is supposed to be trusted on-chip storage which is more protected than PS. And the isolation from TrustZone in normal circumstances should be adequate (at the moment). But physical attacks these days are not that sophisticated anymore, and I think that this is the main driving force for this requirement.
Regards,
George
________________________________
From: Fabian Schmidt
Sent: Thursday, September 23, 2021 3:50 PM
To: Vasilakis, Georgios
Cc: tf-m(a)lists.trustedfirmware.org
Subject: RE: [TF-M] Supporting encryption with ITS
Hi George,
I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.*
Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture.
Greetings,
Fabian Schmidt
* at least short of a sophisticated physical attack or finding some loophole in TrustZone…
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] Supporting encryption with ITS
Caution: EXT Email
Hey all,
Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers.
At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later.
What are your thoughts on this?
Regards,
George
Hey all,
Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers.
At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later.
What are your thoughts on this?
Regards,
George
Hi all,
Please be noted that we are changing the build system to build IPC model by default instead of Library model for the following reasons:
* The Library Model is not being developed anymore. It does not support for new FF-M features.
* New comers to TF-M should be encouraged to start with the IPC model to have the better experiences.
* Most importantly, Library Model will be replaced by SFN Model in future.
Patch here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11384
With this patch, the TFM_PSA_API is not intended for users to choose between library and IPC model anymore.
To build Library model, please set TFM_LIB_MODEL to ON.
The TFM_PSA_API=ON can be kept as is for the time being.
So there would be impacts wherever Library Model is used.
Please get prepared.
Thanks.
Best Regards,
Kevin
Hi,
Another reminder to mention the MMIO binding patches. Several platforms are changed to pass the CI, please platform owners to review the patches, such as:
PSOC: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187
STM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11186
Some of other platform patches are created as well.
This is a significant change for platform which helps much easier integration. After the first series of patches, the problems not covered by the CI need to be fixed adhoc.
Please read the tech forum topic on 2nd Sep for more details or you can just scroll down to check the previous content.
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 30, 2021 5:18 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL
The patchset has updated and now CI passed okay:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 19, 2021 2:16 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL
Hi everyone,
The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries.
Hence, a deeper abstracted interface are provided. Here are the details:
- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.
- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).
- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.
- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.
- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.
We created a patch to showcase the usage on AN521:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.
Now come to the request:
Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.
Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.
Any feedbacks are welcome.
Thank you very much!
/Ken
Hi everyone,
I was wondering is there any reasons to use REGION_NAME(Load$$LR$$, LR_NS_PARTITION, $$Base) declared in this code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> and used here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>?
>From code in common linker script<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> I can see: Load$$LR$$LR_NS_PARTITION$$Base = NS_PARTITION_START.
So the question is: why regions are used instead of simply using NS_PARTITION_START?
And the follow up questions is: do platforms that are built in IPC model (not library model) really need REGION_NAME(Load$$LR$$, LR_VENEER, $$Base)in memory_region_limits memory_regions struct, or that could be just dummy value?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi all,
We decide to move MCUBoot specific configurations to TF-M/bl2/ext/mcuboot folder. This change is to decouple MCUBoot and TF-M configurations and make default_config.cmake clearer.
I have proposed the patch set:
* [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10560>]
I'm grateful to receive any suggestion or enhancement from you.
Best Regards
Jianliang Shen
