Hi Andrej,
please find my replies inline in red.
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 28 May 2019 07:38
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Old Mbed-Crypto library?
Hi Antonio,
> TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0
If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles).
So by using the old mbed-Crypto release, you have downgraded the Crypto API.
[Antonio] Not sure exactly what you mean here. This is the latest Crypto API header used in the development branch:
https://github.com/ARMmbed/mbed-crypto/blob/development/include/psa/crypto.h
And it uses handles instead of slots as I have explained earlier, handles being a newer concept. Also, please bear in mind that the PSA Crypto API development happens on this branch: https://github.com/ARMmbed/mbed-crypto/tree/psa-api-1.0-beta , Mbed Crypto being a reference implementation of the API, which means that the API itself can have new concepts which are not part of the reference implementation yet.
Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects.
[Antonio] TF-M Crypto service is indeed aligned to latest available release of Mbed Crypto, which is Mbed Crypto 1.0.0 (dated 1st April 2019): https://github.com/ARMmbed/mbed-crypto/releases
As soon as there will be new releases, TF-M Crypto will align to those. The TF-M Crypto service is not aligned to the development branch because, as mentioned, that branch undergoes active daily development and would be too difficult to track.
> The psa-arch-test team is in the process of providing an update on the master branch
The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification.
Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch.
Please clarify what PSA-TestSuite branch must be used with TFM now?
[Antonio] The ew_beta0 branch was used as a temporary milestone which was using the old 0.1.0beta API. For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet).
Best regards,
Antonio
Thanks,
Andrej
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Monday, May 27, 2019 6:22 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Old Mbed-Crypto library?
Hi Andrej,
TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes).
Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys.
This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t.
After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks.
Please let me know in case you need any more clarification.
Best regards,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 May 2019 12:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Old Mbed-Crypto library?
Hello,
tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS:
git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0
But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library.
Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests.
We do not want to downgrade our SDK MbedCrypto, better to freeze TFM.
Any plans to use the last Crypto Lib and to revert the PSA API degradation?
Thanks,
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Antonio,
> TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0
If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles).
So by using the old mbed-Crypto release, you have downgraded the Crypto API.
Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects.
> The psa-arch-test team is in the process of providing an update on the master branch
The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification.
Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch.
Please clarify what PSA-TestSuite branch must be used with TFM now?
Thanks,
Andrej
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Monday, May 27, 2019 6:22 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Old Mbed-Crypto library?
Hi Andrej,
TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes).
Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys.
This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t.
After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks.
Please let me know in case you need any more clarification.
Best regards,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 May 2019 12:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Old Mbed-Crypto library?
Hello,
tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS:
git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0
But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library.
Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests.
We do not want to downgrade our SDK MbedCrypto, better to freeze TFM.
Any plans to use the last Crypto Lib and to revert the PSA API degradation?
Thanks,
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Hi Andrej,
TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes).
Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys.
This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t.
After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks.
Please let me know in case you need any more clarification.
Best regards,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 May 2019 12:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Old Mbed-Crypto library?
Hello,
tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS:
git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0
But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library.
Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests.
We do not want to downgrade our SDK MbedCrypto, better to freeze TFM.
Any plans to use the last Crypto Lib and to revert the PSA API degradation?
Thanks,
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS:
git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0
But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library.
Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests.
We do not want to downgrade our SDK MbedCrypto, better to freeze TFM.
Any plans to use the last Crypto Lib and to revert the PSA API degradation?
Thanks,
Andrej Butok
On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote:
>Please see the following link for a design proposal on anti-rollback protection in trusted boot:
>
>https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p…
Somewhat related, as I've been working through a prototype
implementation of SUIT, the SUIT manifest also wants what they call a
"sequence number", which is a monotonically increasing number
associated with each version. They've kind of decided they don't want
to have to do anything like semantic version parsing as part of the
firmware upgrade.
I think this sequence number serves the same purpose as this security
counter (except that the sequence number is required to increase with
each software relase).
One of the goals of the MCUboot community is to make sure that however
the SUIT manifest is implemented, it must be semantically the same as
the existing TLV-format manifest. An easy solution is to just treat
the existing version as a 32-bit number (ignoring the build-id, which
I think is supposed to be the case, anyway).
As far as the possibility of re-using the same security counter value,
I don't think that is something that should be done. In general, it
isn't possible to know where security bugs will be found in an image.
If we always increase the security counter value, someone still
running the immediately following image will be prevented from rolling
back to the version with the security flaw, whereas if we reused the
values, it might be necessary to try to force them to upgrade to a new
version that has the counter increased.
Also, I think it is important to clarify that the security counter is
not required for anti-rollback, it only protects the anti-rollback
implementation from a specific threat: something that is able to
replace the primary firmware image outside of the control of the
bootloader. The cost is that implementing a security counter
generally requires specific hardware just for that purpose. An
entirely software anti-rollback protects against other threats,
including the common case of using the ordinary firmware upgrade
process.
David
Hello,
So, the RTX was replaced by FreeRTOS (regression and psa-tests passed).
Required changes:
1) Use CMSIS-FreeRTOS adapter from: https://github.com/ARM-software/CMSIS-FreeRTOS
2) Do not call os_wrapper_join_thread()/osThreadJoin() and do not use osThreadJoinable flag. It is not supported by FreeRTOS
3) Add missing osThreadExit().
4) Add osDelay(1) to tfm_sst_run_test(), as FreeRTOS free some allocated resources only in the idle task.
5) Disable TFM_NS_CLIENT_IDENTIFICATION to avoid SVC conflict.
5) Other minor changes.
Proposals for general TFM code:
1) Delete os_wrapper_join_thread()/osThreadJoin() as it is optional. It works without it and not supported by all RTOSes.
2) Add missing osThreadExit() to test_task_runner().
3) Do not call each SST test in separate task, or to allow switching to idle task after each SST test.
4) Find other TFM_NS_CLIENT_IDENTIFICATION mechanism, which will not use SVC.
Thanks,
Andrej Butok
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Friday, May 3, 2019 9:36 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS
Hello,
So, even if the unique User ID is optional, it is mandatory for the case when different NS users must have different security asset policies for SST resources.
Is it possible to find another mechanism for the user ID assignment which does not use SVC? To avoid unwanted limitation for FreeRTOS and any other NS application using SVC.
Thanks,
Andrej
-----Original Message-----
From: Miklos Balint <Miklos.Balint(a)arm.com>
Sent: Tuesday, April 30, 2019 5:19 PM
To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: [TF-M] [EXT] Re: TFM and FreeRTOS
Caution: EXT Email
Hi Andrej,
Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1).
That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services.
This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections."
Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4.
Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one.
Let me know if you need further assistance in this matter.
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 25 April 2019 12:47
To: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS
Hi David,
OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API.
In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION.
It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID.
What does it mean? How does it limits the functionality? Is it OK from PSA point of view?
Thanks,
Andrej
-----Original Message-----
From: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Sent: Thursday, April 25, 2019 11:26 AM
To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
Subject: [EXT] Re: [TF-M] TFM and FreeRTOS
Caution: EXT Email
Hi Andrej,
I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following.
In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does.
FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities.
By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core.
Hope it can hlep you.
Best regards,
Hu Ziji
On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote:
> Hello,
>
> Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study?
> I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs.
>
> Thanks,
> Andrej
>
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Hi All,
Please find under the following link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1040 the review of a design document which aim is to fix the implicit casting happening with enumerations in TF-M.
Feel free to add any comments you want on the review!
Kind regards,
Hugues
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
I have uploaded the design document for the TF-M Crypto service at the following Gerrit code review in RST format: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1023
It can be possible to render the HTML format of the design document by checking out the patch above and build the docs (in particular, by building the install_userguide target)
Comments are welcome, here in this thread or preferably in the Gerrit review for better tracking.
Thanks,
Antonio
Hello,
Current TFM SST service supports 1, 2, 4 and 8 Byte minimum write.
Do you have any plan to add the 512 Byte minimal write support to the TFM SST?
LPC55S69 Flash has the 512Bytes program size. Guess, all flash modules with ECC has the same requirement.
Thanks,
Andrej Butok
