Hello,
Following up with the Proposal for Measured Boot Implementation
described in
https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000332.html
, I am working on the implementation of a test fTPM service to exercise
Measured Boot on TF-A.
Some details about the implementation can be found below:
1.- The service will be based on Microsoft's reference implementation
of the TPM 2.0 Specification by TCG. It will be implemented as an OP-
TEE TA.
2.- During service initialisation, the fTPM service will read the TPM
Event Log stored by Measured Boot in Secure Memory and it will extend
it into the PCR specified by the log header.
3.- Alongside with the fTPM service, a test framework based on OP-TEE
Toolkit is being implemented as well. This test framework will generate
and run a Linux/Buildroot environment over a Foundation Model so the
fTPM's PCRs can be accessed to verify its content.
It is important here to highlight that this fTPM service and the
related test framework are meant to be used only for demonstration
purposes, it is not meant to be used as a production implementation.
Please, let me know any comment or query you might have with regards
this.
Best regards,
Javier
Hi,
This is to notify that we are planning to target the Trusted Firmware-A 2.3 release during the third week of April as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.2 release. As part of this, a release candidate tag will be created and release activities will commence from Monday April 6th. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR's) desired to make the 2.2 release are submitted in good time to be complete by Friday April 3rd. Any major enhancement PR's still open after that date will not be merged until after the release.
Thanks & best regards,
[cid:image001.jpg@01D5F78C.8108B010]
Bipin Ravi | Principal Design Enginee
Bipin.ravi(a)arm.com<mailto:Bipin.ravi@arm.com> | Skype: Bipin.Ravi.ARM
Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794
5707 Southwest Parkway, Suite 100, Austin, TX 78735
Hello all,
As the developers community at trustedfirmware.org is growing, there is
an increasing need to have work processes that are clearly documented,
feel smooth and scale well. We think that there is an opportunity to
improve the way the trustedfirmware.org projects are managed today.
That's why we are sharing a project maintenance proposal, focusing on
the TF-A and TF-M projects initially. The aim of this document is to
propose a set of rules, guidelines and processes to try and improve the
way we work together as a community today.
Note that this is an early draft at this stage. This is put up for
further discussion within the trustedfirmware.org community. Nothing is
set in stone yet and it is expected to go under change as feedback from
the community is incorporated.
Please find the initial proposal here:
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
Please provide any feedback you may have by replying to this email
thread, keeping all 4 mailing lists in the recipients list.
I will collate comments from the community and try to incorporate them
in the document, keeping you updated on changes made between revisions.
Regards,
Sandrine
Hi Victor,
There's currently no plan to support Trusted Debug Control, primarily for the lack of an available platform IP component requiring it.
Are you aware of a specific need for a real platform, that could also be available for testing the implementation?
Thanks
Matteo
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Victor Duan via TF-A
Sent: 18 March 2020 01:35
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Trusted Debug Control
Trusted Debug Control specified by TBBR CLIENT is as not supported in the current TF-A v2.2. Is there any plan to support it in the future?
Thank you!
Hi Alexei,
Thanks. This looks good at first glance. However, i do have some
questions that aren't obvious to me by reading the description below and
looking at code. Questions are numbered based on your original email.
Perhaps these can be discussed in the TF-A forum if it is inconvenient
over email.
1) Would be good if the hash alg comes from the config file. This will
make the implementation "crypto agile" from the very beginning. It is
common to want to upgrade/change the hash algorithm and since BL1 is in
ROM, you potentially break measured boot on old devices in case a hash
algorithm is broken. The other option is to get the hash algorithm from
the platform, perhaps a platform gets it from eFuses as opposed to
config files.
2) It looks like you are using memory allocated in the loaded DTB as the
equivalent of a TPM "PCR". How is this protected from direct
modification by BL2? Or is it not protected because BL2 forms a part of
the Root-of-Trust for Measurement(RTM)?(since it's signature is verified
by BL1?)
3) What does "Event Log" refer to? Is it the same event log proposed by
TCG in the platform firmware profile ? As a general question, how close
is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend
measurements for other images ?
4) Would be great not to refer to "TPM" in the measured boot
implementation. Here we are implementing measured boot without a TPM,
but it could be implemented with a TPM. Maybe it should be tcg event log?
5) OK.
6) What does validate event log mean here? More details ?
Thanks
-Raghu
On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote:
> Hello,
>
> I'm preparing the next set of patches for Measured Boot support in TF-A,
> please find some details on design and implementation below.
>
> 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations
> is passed as an existing build 'HASH_ALG' build parameter.
>
> 2. BL1 calculates BL2 image hash and passes these data to BL2 via
> FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array
> added
> in 'fvp_fw_config.dts'.
>
> These changes are part of the patch under review, please see
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555
>
> 3. Event Log is calculated by BL2 in Secure Memory and copied to
> Non-secure memory. Address in Non-secure memory is calculated as:
>
> "nt_fw_config_addr + nt_fw_config_max_size"
>
> with values obtained from 'tb_fw_config':
>
> nt_fw_config_addr = <0x0 0x80000000>;
> nt_fw_config_max_size = <0x200>;
>
> 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG
> device tree in 2 new added properties:
>
> Property name: 'tpm_event_log_addr'
> Value type is an unsigned 64-bit integer specifying the physical address
> of the Event Log.
>
> Property name: 'tpm_event_log_size'
> Value type is an unsigned 32-bit integer specifying the size of the
> Event Log.
>
> /* TPM Event Log Config */
> tpm_event_log {
> compatible = "arm,nt_fw";
> tpm_event_log_addr = <0x0 0x0>;
> tpm_event_log_size = <0x0>;
> };
>
> 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config'
> device tree, which address is passed by BL31 as 'arg0' parameter,
> see TFTF patch:
>
> https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327
>
> 6. A new test which validates and prints Event Log data passed
> in 'nt_fw_config' to BL33 will be added to TFTF.
>
> Please review and provide your comments on the proposed design.
>
> Regards.
> Alexei.
>
> 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.
>
>> As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file.
Thanks for highlighting this. For Tegra platforms, we will provide up to date information to the platform change log after 2.3. We will have to live with the current state of the log for 2.3.
>> Reviewers please continue to help determine if documentation is required for a given patch.
Curious, have there been discussions around automating this somehow? E.g. add a tag to the commit message for a script to pick later.
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Lauren Wehrmeister via TF-A
Sent: Tuesday, March 17, 2020 10:51 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Platforms to maintain their own Change Log files following 2.3 Release
External email: Use caution opening links or attachments
Hi All,
Following the TF-A release planned for April, platforms will be expected to maintain their own Change Log files to document relevant changes in platform specific code. The common TF-A Change Log will no longer document Platform specific updates after the 2.3 release.
As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Reviewers please continue to help determine if documentation is required for a given patch. During each code freeze for a release the documentation in the upcoming change log will be moved to the change log corresponding to the release.
Thanks,
Lauren Wehrmeister
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Hello,
I'm preparing the next set of patches for Measured Boot support in TF-A,
please find some details on design and implementation below.
1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations
is passed as an existing build 'HASH_ALG' build parameter.
2. BL1 calculates BL2 image hash and passes these data to BL2 via
FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array added
in 'fvp_fw_config.dts'.
These changes are part of the patch under review, please see
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555
3. Event Log is calculated by BL2 in Secure Memory and copied to
Non-secure memory. Address in Non-secure memory is calculated as:
"nt_fw_config_addr + nt_fw_config_max_size"
with values obtained from 'tb_fw_config':
nt_fw_config_addr = <0x0 0x80000000>;
nt_fw_config_max_size = <0x200>;
4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG
device tree in 2 new added properties:
Property name: 'tpm_event_log_addr'
Value type is an unsigned 64-bit integer specifying the physical address
of the Event Log.
Property name: 'tpm_event_log_size'
Value type is an unsigned 32-bit integer specifying the size of the Event Log.
/* TPM Event Log Config */
tpm_event_log {
compatible = "arm,nt_fw";
tpm_event_log_addr = <0x0 0x0>;
tpm_event_log_size = <0x0>;
};
5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config'
device tree, which address is passed by BL31 as 'arg0' parameter, see TFTF patch:
https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327
6. A new test which validates and prints Event Log data passed
in 'nt_fw_config' to BL33 will be added to TFTF.
Please review and provide your comments on the proposed design.
Regards.
Alexei.
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,
The second TF-A Tech Forum is scheduled for next week for Thu 26 Mar 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
I have an agenda for next week however for future meetings if other project contributors would also like to present on topics please reach out to me and I will look to schedule.
Agenda:
* Technical Overview of the Fconf (Firmware Configuration) Feature by Louis Mayencourt
* Optional TF-A Mailing List Topic Discussions
Thanks
Joanna
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.
You have been invited to the following event.
Title: TF-A Tech Forum
We run an open technical forum call 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 this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-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 2 weeks from 17:00 to 18:00 on Thursday United Kingdom Time
Where: Zoom
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(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