Hi Andrej,
Thanks for the investigation, we will take a look ASAP.
The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions.
Thanks.
-Ken
________________________________
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: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault
Hi Antonio,
We have own port for LPC55S69, so not sure if you are able to run it.
But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1.
The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform.
Thanks,
Andrej
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault
WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Hi Andrej,
Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue?
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] TFM_PSA_API =>BusFault
Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault.
So this code may not work properly.
Please provide a fix.
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault
Hello,
After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler().
When TFM_PSA_API is not defined, everything is OK.
Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.
Is it known issue? Or something new (during last week) must be added into our target-specific code?
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://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,
We have own port for LPC55S69, so not sure if you are able to run it.
But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1.
The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform.
Thanks,
Andrej
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault
WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Hi Andrej,
Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue?
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] TFM_PSA_API =>BusFault
Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault.
So this code may not work properly.
Please provide a fix.
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault
Hello,
After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler().
When TFM_PSA_API is not defined, everything is OK.
Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.
Is it known issue? Or something new (during last week) must be added into our target-specific code?
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Hi Andrej,
Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue?
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] TFM_PSA_API =>BusFault
Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault.
So this code may not work properly.
Please provide a fix.
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault
Hello,
After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler().
When TFM_PSA_API is not defined, everything is OK.
Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.
Is it known issue? Or something new (during last week) must be added into our target-specific code?
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://lists.trustedfirmware.org/mailman/listinfo/tf-m
Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault.
So this code may not work properly.
Please provide a fix.
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault
Hello,
After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler().
When TFM_PSA_API is not defined, everything is OK.
Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.
Is it known issue? Or something new (during last week) must be added into our target-specific code?
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…
Hello,
After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler().
When TFM_PSA_API is not defined, everything is OK.
Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.
Is it known issue? Or something new (during last week) must be added into our target-specific code?
Thanks,
Andrej Butok
For solving the placement in contiguous region. One possible solution is to modify image format as follow :
header can contain manifest and ih_hdr_size still fixes payload start offset and TLV section starts after sizeof(struct image_header)
Michel
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: lundi 15 avril 2019 16:53
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] FW: Trusted boot - rollback protection
Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number).
The image signature cover these continues blocks in memory:
- image header
- image
- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section)
Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve)
Tamas
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M
Sent: 08 April 2019 16:20
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Trusted boot - rollback protection
For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow :
"an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised."
the impact for this implementation in mcu-boot is limited to :
* The test of the version (security counter is ih_ver from mcuboot header)
* The placement of active image and related manifest data in a trusted memory.
Is my understanding correct ?
As the placement of full image in a trusted memory is a constraint.
Can we limit the information placed in a trusted memory to :
* image header,
* TLV sections.
This seems sufficient to support anti roll back.
Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
We have a candidate fix for issues reported with -Os builds with IPC mode builds, available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/882 could you please help verify if this fixes the issue you're seeing?
Note that also with this patch, the Secure side of SST regression in IPC mode fails, but that is another issue that we have identified and we have a separate patch which will be ready shortly for that.
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M
Sent: 16 April 2019 13:26
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M ARM GCC Optimization issue
Hi Gyorgy,
Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file?
Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more.
Regards
Stanislav
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org
Sent: Tuesday, April 16, 2019 2:00 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [EXT] TF-M Digest, Vol 6, Issue 12
WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.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. FW: Trusted boot - rollback protection (Tamas Ban)
2. TF-M ARM GCC Optimization issue (Stanislav Jancik)
3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Apr 2019 14:52:49 +0000
From: Tamas Ban <Tamas.Ban(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] FW: Trusted boot - rollback protection
Message-ID:
<AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number).
The image signature cover these continues blocks in memory:
- image header
- image
- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section)
Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve)
Tamas
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M
Sent: 08 April 2019 16:20
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Trusted boot - rollback protection
For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow :
"an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised."
the impact for this implementation in mcu-boot is limited to :
* The test of the version (security counter is ih_ver from mcuboot header)
* The placement of active image and related manifest data in a trusted memory.
Is my understanding correct ?
As the placement of full image in a trusted memory is a constraint.
Can we limit the information placed in a trusted memory to :
* image header,
* TLV sections.
This seems sufficient to support anti roll back.
Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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.
------------------------------
Message: 2
Date: Tue, 16 Apr 2019 11:21:05 +0000
From: Stanislav Jancik <stanislav.jancik(a)nxp.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] TF-M ARM GCC Optimization issue
Message-ID:
<VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler.
For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly.
I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler.
Did you try to use different optimization at Musca boards as well?
Regards
Stanislav
------------------------------
Message: 3
Date: Tue, 16 Apr 2019 11:58:29 +0000
From: Gyorgy Szing <Gyorgy.Szing(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] TF-M ARM GCC Optimization issue
Message-ID:
<VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Stanislav,
Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting?
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M
Sent: 16 April 2019 13:21
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M ARM GCC Optimization issue
Hi,
I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler.
For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly.
I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler.
Did you try to use different optimization at Musca boards as well?
Regards
Stanislav
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
Subject: Digest Footer
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
End of TF-M Digest, Vol 6, Issue 12
***********************************
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Gyorgy,
Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file?
Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more.
Regards
Stanislav
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org
Sent: Tuesday, April 16, 2019 2:00 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [EXT] TF-M Digest, Vol 6, Issue 12
WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.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. FW: Trusted boot - rollback protection (Tamas Ban)
2. TF-M ARM GCC Optimization issue (Stanislav Jancik)
3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Apr 2019 14:52:49 +0000
From: Tamas Ban <Tamas.Ban(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] FW: Trusted boot - rollback protection
Message-ID:
<AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number).
The image signature cover these continues blocks in memory:
- image header
- image
- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section)
Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve)
Tamas
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M
Sent: 08 April 2019 16:20
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Trusted boot - rollback protection
For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow :
"an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised."
the impact for this implementation in mcu-boot is limited to :
* The test of the version (security counter is ih_ver from mcuboot header)
* The placement of active image and related manifest data in a trusted memory.
Is my understanding correct ?
As the placement of full image in a trusted memory is a constraint.
Can we limit the information placed in a trusted memory to :
* image header,
* TLV sections.
This seems sufficient to support anti roll back.
Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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.
------------------------------
Message: 2
Date: Tue, 16 Apr 2019 11:21:05 +0000
From: Stanislav Jancik <stanislav.jancik(a)nxp.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] TF-M ARM GCC Optimization issue
Message-ID:
<VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler.
For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly.
I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler.
Did you try to use different optimization at Musca boards as well?
Regards
Stanislav
------------------------------
Message: 3
Date: Tue, 16 Apr 2019 11:58:29 +0000
From: Gyorgy Szing <Gyorgy.Szing(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] TF-M ARM GCC Optimization issue
Message-ID:
<VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Stanislav,
Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting?
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M
Sent: 16 April 2019 13:21
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M ARM GCC Optimization issue
Hi,
I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler.
For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly.
I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler.
Did you try to use different optimization at Musca boards as well?
Regards
Stanislav
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
Subject: Digest Footer
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
End of TF-M Digest, Vol 6, Issue 12
***********************************
Hi Stanislav,
Can you please check if the issue described here https://developer.trustedfirmware.org/T234 is the same as you are reporting?
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M
Sent: 16 April 2019 13:21
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M ARM GCC Optimization issue
Hi,
I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler.
For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly.
I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler.
Did you try to use different optimization at Musca boards as well?
Regards
Stanislav
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
