Hi Thomas,
Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs.
Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different.
Kind regards,
Jamie
From: Thomas Törnblom <thomas.tornblom(a)iar.com>
Sent: 02 December 2019 22:50
To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Regression test issues with IAR port
Hi Jamie,
From tfm_sst_test_1018_task_2():
---
...
uint8_t read_data[] = READ_DATA;
status = psa_ps_get(uid, offset, data_len, read_data);
if (status != PSA_PS_ERROR_UID_NOT_FOUND) {
TEST_FAIL("Get should not succeed with invalid thread name");
return;
}
/* Check that read data has not been modified */
if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) {
TEST_FAIL("Read data should not have changed");
return;
}
...
---
The call to psa_ps_get() returns 0, which is a failure in this test.
Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX".
This appears to happen in the following call chain:
sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy()
As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related.
sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req()
I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get().
It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020.
I'll continue debugging this...
Cheers,
Thomas
Den 2019-11-28 kl. 17:37, skrev Jamie Fox:
Hi Thomas,
We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think.
Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping.
The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread.
Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there?
Kind regards,
Jamie
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 28 November 2019 15:45
To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com><mailto:nd@arm.com>
Subject: Re: [TF-M] Regression test issues with IAR port
Sorry, I was being unclear.
I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread.
The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there.
Cheers,
Thomas
Den 2019-11-28 kl. 16:00, skrev Minos Galanakis:
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure
suite.
For SST The logic is located at :
* Non Secure side tests:
test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests:
test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
----------------------------------------------------------------------
--
*From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of
Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org>
*Sent:* 28 November 2019 14:49
*To:* tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org>
*Subject:* [TF-M] Regression test issues with IAR port In my quest to
port TF-M to the IAR toolchain I've run into issues with a few of the
tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con
figs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
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> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com>
Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
<http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems>
<http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
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,
As part of some of our work on TF-M, specifically around attestation,
device provisioning and firmware management, we've been reviewing some of
what various companies are currently doing or requiring during the
provisioning process (whether provisioning at the manufacturing phase, or
provisioning devices into cloud or similar services post manufacturing).
The common thread in almost all of these scenarios is the use of X.509
certification chains when working with the public key(s) held on the end
device.
At Linaro, we've been thinking through some of the benefits and tradeoffs
of migrating from the current approach of exposing unsigned public keys for
things like initial attestation and signing firmware, and what would be
required to allow the signing of the attestation/firmware keys on devices,
and generating new keys such as provisioning a device onto an
Amazon/Google/Microsoft cloud service which would require creating a new
private key held in secure storage, and storing the signed certificate
chain associated with that new private key for on-demand retrieval.
- Some of the initial thinking and imagined benefits of migrating to X.509
certificate chains are described here:
https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md
- Some general notes on X.509 certificates are available here:
https://github.com/microbuilder/certificate_chains/blob/master/README.md
- And here are two scripts showing how to create 2 and 3 level certificate
chains, just as a proof of concept to better understand how this might work
with something like TF-M:
-
https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr…
-
https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr…
Specifically, they key missing aspects to enable the use of standard X.509
certificates are:
- Update mcuboot to understand a certificate chain -- rather than the raw
public key -- when verifying firmware images
- Generating PKSC#10 (RFC2986) certificate signing requests on the secure
side, using a securely held private key during the request generation
process
- Generate new private keys and store them in secure storage for
non-attestation uses like cloud services, and retrieve the associated and
signed cert chains for that key on demand
A proposal of how this might work in the real world is shown here, with the
TF-M secure code requrements in the 'opt' box of the sequence diagram:
https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c…
We don't have a full TF-M proof of concept ready yet, but wanted to put the
idea on the table of migrating to X.509 certificate chains while we work on
a proof of concept, and continue analysis of how provision at manufacturing
and in the field (to cloud services, etc.) can be improved.
Any feedback/concerns is welcome here or perhaps in the Github repo above
until a specific change request can be prepared for TF-M.
Best regards,
Kevin Townsend
In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed.
Alan
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M
Sent: Friday, November 22, 2019 2:15 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build
Hi all,
I'm having issues on supporting the out of tree build.
So I'd like to propose some additional changes.
What does the out of tree build currently support is that:
The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M.
And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building.
The problem is that some of the source files include the generated headers using the relative path to where the source itself is.
And the directory of the source file is always searched first.
This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list.
So I suggest to put the generated files to a dedicated directory in TF-M.
Then for the default build, add the directory and its subdirectories to the search list for headers.
For out of tree build, use the specified directory and its subdirectories instead.
Then there would only one header file with the same name in all the directories for searching headers.
Any concerns, thoughts or suggestions?
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng (Arm Technology China)
Sent: Friday, November 22, 2019 3:45 PM
To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build
Hi Alan,
I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606
The changes for build system is ongoing.
The functionality changes for the tfm_parse_manifest_list.py is the same as your version.
Please have a review and help verify it if possible.
Comments from anyone else are also welcome.
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng (Arm Technology China)
Sent: Thursday, November 14, 2019 3:31 PM
To: DeMars, Alan <ademars(a)ti.com>
Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build
OK.
It's much clearer for me now. Thanks.
Best Regards,
Kevin
-----Original Message-----
From: DeMars, Alan <ademars(a)ti.com>
Sent: Thursday, November 14, 2019 10:34 AM
To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build
1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files.
2) Yes, I’m building using the unmodified master branch’s cmake build system.
3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree.
Alan
> On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi Alan,
>
> I checked your modified tfm_parse_manifest_list.py.
> It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input.
>
> I'm sorry I was not in the workshop. So I have some questions.
> 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M?
> 2. Are you using the TF-M provided CMake build system?
> 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory?
>
> Could you provide some details about your requirements. Thanks.
>
> Best Regards,
> Kevin
>
> -----Original Message-----
> From: Kevin Peng (Arm Technology China)
> Sent: Wednesday, November 13, 2019 10:27 AM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: RE: out of tree build
>
> Hi Alan,
>
> I'm following on this and will get you updated on any progress.
>
> Best Regards,
> Kevin
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
> Sent: Thursday, November 7, 2019 12:42 PM
> To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> Subject: Re: [TF-M] out of tree build
>
> Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted.
> ---
>
> With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line:
>
> python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir>
>
> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line:
>
> cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../
>
> The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage.
>
> Alan
>
>
> -----Original Message-----
> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M
> Sent: Monday, November 4, 2019 4:36 PM
> To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org
> Subject: [EXTERNAL] Re: [TF-M] out of tree build
>
> Abishek,
>
> Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory.
> A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files.
>
> I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible.
>
> Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise.
>
> Alan
>
> -----Original Message-----
> From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com]
> Sent: Monday, November 4, 2019 3:08 PM
> To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org
> Subject: [EXTERNAL] RE: out of tree build
>
> Hi Alan,
> Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review?
> Thanks,
> Abhishek
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
> Sent: 01 November 2019 16:29
> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> Subject: [TF-M] out of tree build
>
> Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them.
>
> Alan
> --
> 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
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi all,
As mentioned in the TF-M workshop in Lyon last month, we propose to kick
off the TF-M Technical Forum meeting, starting on the 5th December. This is
an open forum for anyone to participate and it is not restricted to TF
members. It will operate under the guidance of the TF TSC.
- Due to expected attendees from Asia, Europe and the Americas, the
timeslot is challenging. We hope it's not too difficult for anyone - we can
review after the first couple of meetings.
- Initially we propose a bi-weekly call and then we'll change cadence
depending on interest
For more details of the call click on the Google Calendar image at
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi,
A new tag TF-Mv1.0-RC3 was created last Friday. The main change since RC2 is that it provides support for integrated Cryptocell-312 cryptographic hardware accelerator on MuscaB1e platform.
This enables TF-M to make use of Cryptocell-312 (CC-312) for crypto acceleration during Secure boot and runtime. TF-M is also can use the provisioned HUK (Hardware Unique Key), Attestation key and RoTPK (Root of Trust Public Key) in Cryptocell's OTP memory.
Tamas
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure suite.
For SST The logic is located at :
* Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 28 November 2019 14:49
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Regression test issues with IAR port
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
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> <http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
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 Andrej/Kevin,
Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile*
It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met.
PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage,
maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform.
@Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this
>>>
5.3 F.SECURE_STORAGE
The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to
the platform. Only the TOE can retrieve and modify assets from this secure storage.
This security function mitigates T.STORAGE by preventing direct and unprotected access to assets.
>>>
Regards,
Shebu
* https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le…
** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im…
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Thursday, November 28, 2019 7:50 AM
To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA Certification without PS?
Hi Kevin,
So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right?
Thank you for your clarification,
Andrej Butok
-----Original Message-----
From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>>
Sent: Thursday, November 28, 2019 5:14 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] PSA Certification without PS?
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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<mailto:TF-M@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.
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Ken, all,
Right, let's see the binary size of a prototype.
Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 22 November 2019 10:23
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] The svcall switch-case vs function table
Hi Anton,
Thanks for the reminder.
About code size, two points:
- We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func();
- The compiler uses 'TBB' instruction, which is a function table already.
So I think it should be okay; we can verify the code size after the prototype is available.
BR
/Ken
-----Original Message-----
From: Anton Komlev <Anton.Komlev(a)arm.com>
Sent: Thursday, November 21, 2019 8:09 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>
Subject: RE: The svcall switch-case vs function table
Hi Ken, All,
Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase.
This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 14 November 2019 09:33
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] The svcall switch-case vs function table
Hi,
I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations.
Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros?
This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros.
Welcome to comment or propose patches for this.
Thanks.
/Ken
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
