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
Hi all,
I'd like to merge the following patch set tomorrow, if there is no more major comment.
* Decouple tf-m-tests specific config setting from trusted-firmware-m.
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11167>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11169>]
* Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log.
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11153>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11131/>]
After the above patches are merged, there are two major changes:
* tf-m-tests dedicated configuration setup process will be moved to tf-m-test repo, from TF-M. Therefore you can update tf-m-tests config setting, without modifying TF-M repo.
* Tf-m-tests commit ID is specified in TF-M `lib\ext\tf-m-tests\repo_config_default.cmake`, rather than in TF-M main `config_default.cmake`. You can update tf-m-tests commit ID in TF-M without touching the large `config_default.cmake`.
Any suggestion or comment is always welcome!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, August 24, 2021 5:33 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Hi all,
As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo.
The purpose of the decoupling enhancement includes:
* Making it more easier to integrate TF-M and port tf-m-tests
* Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system.
* Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M
Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test.
Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M.
So far we have proposed the following major changes:
* Decouple tf-m-tests specific config setting from trusted-firmware-m.
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11167>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11169/1>]
* Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10647>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10556>]
More patch sets for decoupling are under review as well.
* Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log.
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11153>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11131/3>]
* Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests
[TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11181>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11182>]
I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome.
If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me.
Thanks in advance.
Best regards,
Hu Ziji
Hello everyone.
After building the project interface/include/multi_core/tfm_mailbox_config.h is generated, but it is not in .gitignore
I think this file should be in .gitignore because it is build artifact and is really annoying to deal with.
Am I wrong somewhere?
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 are going to remove some test cases in tfm_core_test. They are:
* TFM_INTERACTIVE_TEST
* TFM_PERIPH_ACCESS_TEST
The main reasons is that these peripheral and interactive test cases are mainly platform specific(button and LEDs),
rather than test the main features and secure functionalities of TF-M. Besides, it also a burden for flatform owner
to support and maintain those test cases.
Do you have any concerns for remove those test cases?
Best Regards,
Shawn
Hi,
The next Technical Forum is planned on Thursday, Sep 16, 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Ken, Hu,
I just saw this message now and wanted to give my perspective based on some of the code Renesas has developed.
In general, the primary benefits of having enums are return codes are type checking and portability.
So of you have a top level application using an API that always returns an error from a defined enum list, then the application can switch to using different implementations of the same API and does not have to change its error handling code etc.
However, if you are returning uint32 instead then its likely that different implementations of the same API will have any possible return code making the application non-portable.
I think the issue arises when the enum list is not sufficiently well defined so each enum entry ends up acting as a funnel for x number of lower level error code so there is loss of information etc.
But w.r.t the line in the TFM coding guide : " Use enumeration for error codes to keep the code readable.", if the objective is just to make the code readable, then you don’t really need an enum for that... you can achieve readability by using #define XYZ_error. I think that will be much harder to maintain particularly in terms of preventing different error codes from being defined to the same value unless we have a common file where all error code are defined for a specific layer.
-Michael
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of tf-m-request(a)lists.trustedfirmware.org
Sent: Friday, September 3, 2021 4:38 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: TF-M Digest, Vol 35, Issue 6
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
or, via email, send a message with subject or body 'help' to
tf-m-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
tf-m-owner(a)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. Re: [RFC] Can we remove the rule to use enum for error code?
(Ken Liu)
2. Re: [RFC] Can we remove the rule to use enum for error code?
(Andrew Thoelke)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Sep 2021 07:54:41 +0000
From: Ken Liu <Ken.Liu(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error
code?
Message-ID:
<DBBPR08MB4741B0807FC4ACD9F4466520F5CF9(a)DBBPR08MB4741.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
I am okay to remove it.
Even it can be used to check the error types, but some of the developers do typecast on enum which makes the rule no sense.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Friday, September 3, 2021 3:45 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code?
Hi all,
Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>:
* Use enumeration for error codes to keep the code readable.
Personally, I’d prefer macros to enum, for error codes.
* The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this.
* Using macros to define error codes aligns with PSA return code definitions.
* Enum makes function and variable definitions longer
* Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one.
* Error codes for errors are usually negative but enums are positive ones by default.
I’d like to propose to remove this rule from TF-M coding standard.
But it doesn’t mean that enum shall not be used anymore.
I’m wondering if macros for error code in TF-M can be approved as well. 😊
May I know your opinions please?
If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot!
Best regards,
Hu Ziji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…>
------------------------------
Message: 2
Date: Fri, 3 Sep 2021 08:38:02 +0000
From: Andrew Thoelke <Andrew.Thoelke(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error
code?
Message-ID:
<DB7PR08MB38651B33CD7BAEB9BF05F0229ACF9(a)DB7PR08MB3865.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi,
In my experience, the only significant benefit of using enums is that some debuggers display the symbolic name for a value with the enum type.
But, as already mentioned, using enums does not help in parsing logs, or decoding error values in integer variables/registers; particularly when the definition does not provide explicit values for each identifier.
In addition, the rules for determining the implicit integer type for an enum type are non-trivial. This results in a lack of transparency when reading or reviewing code with respect to the size of the enum type in a data structure, or the behaviour when converting an enum value to an integer (or back again).
This is why the PSA specifications use explicitly sized integer types for types like psa_status_t, and macros to define values of such types.
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 03 September 2021 08:45
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code?
Hi all,
Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>:
* Use enumeration for error codes to keep the code readable.
Personally, I’d prefer macros to enum, for error codes.
* The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this.
* Using macros to define error codes aligns with PSA return code definitions.
* Enum makes function and variable definitions longer
* Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one.
* Error codes for errors are usually negative but enums are positive ones by default.
I’d like to propose to remove this rule from TF-M coding standard.
But it doesn’t mean that enum shall not be used anymore.
I’m wondering if macros for error code in TF-M can be approved as well. 😊
May I know your opinions please?
If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot!
Best regards,
Hu Ziji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…>
------------------------------
Subject: Digest Footer
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
End of TF-M Digest, Vol 35, Issue 6
***********************************
Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.
Hi,
The following patch enables the flash read/write with unaligned address/cnt for MCUboot and Firmware Update partition.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10947
This patch has been merged and thanks to all who have reviewed on this patch.
As this patch can impact the MCUboot booting up on the platforms, if there is any booting up issue on your platform after this commit, do not hesitate to feedback to me. 😊
Thanks,
Regards,
Sherry Zhang
