Hi,
I let you notify that 'INDIVIDUAL_SW_COMPONENTS' support is planned to be removed from attestation service and bootloader.
What is this?
* Boootloader and SPE can exchange data through shared memory. This is needed to provide the boot status info to attestation service. The boot status info is included in the SW_COMPONENT claim in the attestation token.
* Until now two types of data encoding was supported during this data sharing:
* All boot status data item is passed as a single TLV entry: -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS
* Boot status is already encoded to CBOR format at build time. Bootloader only updates a few field in it, and pass the CBOR object to SPE. Then attestation service just include this already CBOR formatted object to the token, without the need to applying further encoding.
-DATTEST_BOOT_INTERFACE=CBOR_ENCODED_CLAIMS
The 'INDIVIDUAL_CLAIMS' format is marked as deprecated feature for a while in the code base. Now the plan is to remove it and rely fully on the 'CBOR_ENCODED_CLAIMS' format.
The build system support for this is present in TF-M for a long, and recently it was upstream to original MCUBoot 'imgtool' script as well. Next MCUBoot release (v1.6) will contain it.
If you has any objection, because your project is using the 'INDIVIDUAL_CLAIMS' format then please let us know!
BR,
Tamas
Hi all,
Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions.
I'd like to request a final round review.
If no further critical comment, the Profile Small design document will be merged next Wednesday.
If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598.
Best regards,
Hu Ziji
You have been invited to the following event.
Title: TF-M tech Forum (Asia TZ)
About TF-M Tech forum:This is an open forum for anyone to participate and
it is not restricted to Trusted Firmware project members. It will operate
under the guidance of the TF TSC.Feel free to forward it to
colleagues.Details of previous meetings are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656
US (New York) +1 669 900 9128 US (San
Jose) 877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
When: Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 May to Sat
1 Aug United Kingdom Time
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Bill Fletcher- creator
* tf-m(a)lists.trustedfirmware.org
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=MjJva2xwOGVxaG12bHVha…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
You have been invited to the following event.
Title: TF-M Tech Forum (US TZ)
About TF-M Tech forum:This is an open forum for anyone to participate and
it is not restricted to Trusted Firmware project members. It will operate
under the guidance of the TF TSC.Feel free to forward it to
colleagues.Details of previous meetings are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656
US (New York) +1 669 900 9128 US (San
Jose) 877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
When: Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat
1 Aug United Kingdom Time
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Bill Fletcher- creator
* tf-m(a)lists.trustedfirmware.org
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=MW5vZW9lcmloY2l2aWhpa…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi all,
I've received very little feedback on version 2 of the proposal, which
hints that we are reaching an agreement. Thus, I plan to finalize the
proposal this week. This can then become part of our development flow
for all trustedfirmware.org projects.
Thanks again for all the inputs!
Regards,
Sandrine Bailleux
Hi all,
I uploaded a patch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/4009) to simplify/improve the entry points of secure functions in Library model.
In current Library model implementation, each secure function includes the same inline entry point tfm_core_partition_request(). Actually, only the NS client check is required to be inline. The duplicated entry points cost much code size.
Thus this patch extracts NS client check and make it as a simple inline function tfm_core_is_ns_client(). tfm_core_partition_request() becomes a normal function called by each secure function.
Some quantitative results of code size optimization (about 3KB) are shown below:
Profile Small (ConfigDefaultProfileS) is based on https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o…
ConfigDefault + Armclang 6.10 + Release + AN521
Code
RO-data
RW-data
ZI-data
Current impl
129778
8994
272
50108
Improved
126294
8994
272
50108
ConfigDefaultProfileS + Armclang 6.10 + Release + AN521
Code
RO-data
RW-data
ZI-data
Current impl
55886
3274
200
31664
Improved
52930
3274
200
31664
Best regards,
Hu Ziji
Hi Raymond,
There are some changes required for PSoC64 target with the recent changes from Jamie on persistent key support for test_c050 (api-tests/dev_apis/crypto/test_c050).
I will be pushing changes to GitHub today.
You could try them and let us know if you are still facing problem.
Regards,
Vinay
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, April 27, 2020 8:03 AM
To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Jamie Fox <Jamie.Fox(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] PSA Crypto failure with addition of persistent keys
Hi Raymond,
Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250.
Could you please share more details and error logs of this test case?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M
Sent: Monday, April 27, 2020 10:26 AM
To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com>
Subject: [TF-M] PSA Crypto failure with addition of persistent keys
Hi Jamie,
With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack.
Thank you,
Ray
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
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.
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.