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
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
Hello team,
This is an email requesting reviews for the latest Tegra platform changes [1] from our downstream branch.
Please review these changes at the earliest and help us get them merged before the release candidate tag is generated. We hope to push one more batch for v2.3, after [1] gets merged.
Thanks in advance.
Varun
[1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-03122020%22+…
-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
Hi Sumit,
On 3/4/20 4:55 PM, Sumit Garg via TF-A wrote:
>> The last remaining item would be to address the MISRA violations
>> that Coverity found, which I've copied & pasted for you on Gerrit in the
>> top patch.
>
> I have tried to address most of MISRA violations and updated the
> patch-set. But since I don't have access to Coverity tool you are
> using, so can you please check if there is any relevant MISRA
> violation that I missed?
Sure, I will re-run the tool in our internal CI and let you know the
results.
>> Also, this feature is only used on QEMU right now and I am not aware of
>> anyone trying to enable it for their platforms just yet. Thus there is a
>> risk we might have overlooked some issues that we'll discover at that time.
>
> Socionext being a silicon vendor is actively looking for this feature
> and I think they will build upon this feature to enable firmware
> encryption on their platforms to meet DRM robustness rules.
Interesting, thanks for sharing this information.
>> Furthermore, I know that you've done some testing of this feature on
>> QEMU but this is not integrated into the CI loop right now. Thus, there
>> is a risk that we might break it in the future and this will go
>> unnoticed, unless you plan to test it regularly on your end.
>
> Yeah we should plan to enable testing for this feature in CI loop.
For now, I've added in our internal CI a simple build test based on the
build instructions you've provided in the patch set. This will at least
make sure we do not break the build inadvertently in the future.
But as you say, going forward, we should plan for proper testing on
QEMU. I am hoping we will soon be able to extend the OpenCI [1] and add
this support there.
[1]
https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000264.html
>> * Saying so in the (upcoming) change log.
>
> I hope you can take care of this.
Actually this is something you have access to, it's a matter of adding a
line in docs/change-log-upcoming.rst in the TF-A source tree.
Regards,
Sandrine
Hi Everyone,
I have tried to address most of the implementation concerns with updated
patch-set [1] as follows:
*Concern*: Firmware encryption bit needs to be signed
*Address*: Moved the firmware encryption bit from FIP ToC header to
"io_uuid_spec_t" struct which is part of "plat_io_policy" that is embedded
in the boot-loader (BL1 or BL2) and hence firmware encryption bit is signed.
Also, with this implementation fip_tool is no longer aware of encryption
and just encrypted binaries are piped to fip_tool.
*Concern*: Capability to encrypt with different keys for different images
*Address*: Passed "img_id" buffer reference as an argument of
"plat_get_enc_key_info()" API. So that platforms may choose to either
provide a unique key per firmware image or just derive a key from HUK per
firmware using "img_id" buffer as a salt.
*Concern*: Coupling of FIP and encryption layer
*Address*: Firstly I think we all can agree that encryption layer provides
confidentiality protection specific to IO storage. Secondly FIP is actually
a packaging layer that sits over actual IO layer and having the encryption
layer coupled with FIP provides an abstraction layer for any FIP payload
which in turn provides the following features:
1. Allows the firmware certificates to be encrypted as well to protect
against cloning satisfying R050_TBBR_PROTECTION requirement.
2. Allows the firmware configuration data to be encrypted as well.
3. Provides a capability to have a secure key store as FIP payload which is
protected using HUK.
*Concern*: Allow usage of alternative verify-then-decrypt method
*Address*: A platform could disable this encryption layer and implement
decryption as part of "bl2_plat_handle_post_image_load()".
Please let me know in case I missed any implementation concerns and feel
free to provide your feedback on updated patch-set [1].
[1]
https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op…
Regards,
Sumit
Hi Masahiro,
That warning is expected. GCC complains about this, since tf_base_xlat_table is not constant and we are asking it to be put in a read-only section (see the REGISTER_XLAT_CONTEXT_RO_BASE_TABLE macro). This is fine since:
* We only want the base table to be read-only after the tables have been initialized. The only time we change tf_base_xlat_table is when we initialize it, and at that point in the platform setup sequence the MMU is off, so permissions have no effect.
* We never write to this with the MMU on (it's the level 1 translation table), so there is no danger of generating MMU faults.
I hope this answers your question.
Thanks
Petre
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Masahiro Yamada via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 06 March 2020 12:30
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1
Hi.
If I build TF-A with ALLOW_RO_XLAT_TABLES=1,
the base xlat table goes into .rodata section
instead of .bss section.
Then, I see a warning like:
/tmp/ccswitLr.s: Assembler messages:
/tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata
Is this a know issue?
[Reproduce Command]
make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1
The full build log is below:
masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp
CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1
CC lib/libfdt/fdt.c
CC lib/libfdt/fdt_addresses.c
CC lib/libfdt/fdt_empty_tree.c
CC lib/libfdt/fdt_ro.c
CC lib/libfdt/fdt_rw.c
CC lib/libfdt/fdt_strerror.c
CC lib/libfdt/fdt_sw.c
CC lib/libfdt/fdt_wip.c
AR build/fvp/release/lib/libfdt.a
Building fvp
CC lib/libc/abort.c
CC lib/libc/assert.c
CC lib/libc/exit.c
CC lib/libc/memchr.c
CC lib/libc/memcmp.c
CC lib/libc/memcpy.c
CC lib/libc/memmove.c
CC lib/libc/memrchr.c
CC lib/libc/memset.c
CC lib/libc/printf.c
CC lib/libc/putchar.c
CC lib/libc/puts.c
CC lib/libc/snprintf.c
CC lib/libc/strchr.c
CC lib/libc/strcmp.c
CC lib/libc/strlcpy.c
CC lib/libc/strlen.c
CC lib/libc/strncmp.c
CC lib/libc/strnlen.c
CC lib/libc/strrchr.c
AS lib/libc/aarch64/setjmp.S
AR build/fvp/release/lib/libc.a
CC drivers/arm/smmu/smmu_v3.c
CC drivers/arm/sp805/sp805.c
CC drivers/delay_timer/delay_timer.c
CC drivers/io/io_semihosting.c
CC lib/semihosting/semihosting.c
CC plat/arm/board/fvp/fvp_bl1_setup.c
CC plat/arm/board/fvp/fvp_err.c
CC plat/arm/board/fvp/fvp_io_storage.c
CC drivers/arm/cci/cci.c
CC drivers/delay_timer/generic_delay_timer.c
CC drivers/cfi/v2m/v2m_flash.c
CC drivers/io/io_fip.c
CC drivers/io/io_memmap.c
CC drivers/io/io_storage.c
CC plat/arm/common/arm_bl1_setup.c
CC plat/arm/common/arm_err.c
CC plat/arm/common/arm_fconf_io_storage.c
CC plat/arm/common/fconf/arm_fconf_io.c
CC lib/fconf/fconf.c
CC lib/fconf/fconf_dyn_cfg_getter.c
CC plat/arm/common/arm_dyn_cfg.c
CC plat/arm/common/arm_dyn_cfg_helpers.c
CC common/fdt_wrappers.c
CC bl1/bl1_main.c
CC bl1/aarch64/bl1_arch_setup.c
CC bl1/aarch64/bl1_context_mgmt.c
CC lib/cpus/errata_report.c
CC lib/el3_runtime/aarch64/context_mgmt.c
CC plat/common/plat_bl1_common.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS lib/semihosting/aarch64/semihosting_call.S
AS plat/arm/board/fvp/aarch64/fvp_helpers.S
AS lib/cpus/aarch64/aem_generic.S
AS lib/cpus/aarch64/cortex_a35.S
AS lib/cpus/aarch64/cortex_a53.S
AS lib/cpus/aarch64/cortex_a57.S
AS lib/cpus/aarch64/cortex_a72.S
AS lib/cpus/aarch64/cortex_a73.S
AS bl1/aarch64/bl1_entrypoint.S
AS bl1/aarch64/bl1_exceptions.S
AS lib/cpus/aarch64/cpu_helpers.S
AS plat/common/aarch64/platform_up_stack.S
AS lib/cpus/aarch64/dsu_helpers.S
AS lib/el3_runtime/aarch64/context.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl1/bl1.ld.S
LD build/fvp/release/bl1/bl1.elf
BIN build/fvp/release/bl1.bin
Built build/fvp/release/bl1.bin successfully
OD build/fvp/release/bl1/bl1.dump
CC drivers/arm/sp805/sp805.c
CC drivers/io/io_semihosting.c
CC lib/utils/mem_region.c
CC lib/semihosting/semihosting.c
CC plat/arm/board/fvp/fvp_bl2_setup.c
CC plat/arm/board/fvp/fvp_err.c
CC plat/arm/board/fvp/fvp_io_storage.c
CC plat/arm/common/arm_nor_psci_mem_protect.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/cfi/v2m/v2m_flash.c
CC drivers/delay_timer/delay_timer.c
CC drivers/delay_timer/generic_delay_timer.c
CC drivers/io/io_fip.c
CC drivers/io/io_memmap.c
CC drivers/io/io_storage.c
CC plat/arm/common/arm_bl2_setup.c
CC plat/arm/common/arm_err.c
CC plat/arm/common/arm_fconf_io_storage.c
CC plat/arm/common/fconf/arm_fconf_io.c
CC lib/fconf/fconf.c
CC lib/fconf/fconf_dyn_cfg_getter.c
CC plat/arm/common/arm_dyn_cfg.c
CC plat/arm/common/arm_dyn_cfg_helpers.c
CC common/fdt_wrappers.c
CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c
CC plat/arm/common/arm_image_load.c
CC common/desc_image_load.c
CC bl2/bl2_image_load_v2.c
CC bl2/bl2_main.c
CC bl2/aarch64/bl2_arch_setup.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS lib/semihosting/aarch64/semihosting_call.S
AS lib/locks/exclusive/aarch64/spinlock.S
AS plat/common/aarch64/platform_up_stack.S
AS common/aarch64/early_exceptions.S
AS bl2/aarch64/bl2_entrypoint.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl2/bl2.ld.S
LD build/fvp/release/bl2/bl2.elf
BIN build/fvp/release/bl2.bin
Built build/fvp/release/bl2.bin successfully
OD build/fvp/release/bl2/bl2.dump
CC drivers/arm/fvp/fvp_pwrc.c
CC drivers/arm/smmu/smmu_v3.c
CC drivers/delay_timer/delay_timer.c
CC drivers/cfi/v2m/v2m_flash.c
CC lib/utils/mem_region.c
CC plat/arm/board/fvp/fvp_bl31_setup.c
CC plat/arm/board/fvp/fvp_pm.c
CC plat/arm/board/fvp/fvp_topology.c
CC plat/arm/common/arm_nor_psci_mem_protect.c
CC drivers/arm/gic/common/gic_common.c
CC drivers/arm/gic/v3/gicv3_main.c
CC drivers/arm/gic/v3/gicv3_helpers.c
CC plat/common/plat_gicv3.c
CC plat/arm/common/arm_gicv3.c
CC drivers/arm/gic/v3/gic500.c
CC drivers/arm/cci/cci.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/delay_timer/generic_delay_timer.c
CC lib/cpus/aarch64/cpuamu.c
CC plat/arm/common/arm_bl31_setup.c
CC plat/arm/common/arm_pm.c
CC plat/arm/common/arm_topology.c
CC plat/common/plat_psci_common.c
CC plat/arm/common/aarch64/execution_state_switch.c
CC plat/arm/common/arm_sip_svc.c
CC lib/pmf/pmf_smc.c
CC bl31/bl31_main.c
CC bl31/interrupt_mgmt.c
CC bl31/bl31_context_mgmt.c
CC common/runtime_svc.c
CC services/arm_arch_svc/arm_arch_svc_setup.c
CC services/std_svc/std_svc_setup.c
CC lib/el3_runtime/cpu_data_array.c
CC lib/el3_runtime/aarch64/context_mgmt.c
CC lib/cpus/errata_report.c
CC lib/psci/psci_off.c
CC lib/psci/psci_on.c
CC lib/psci/psci_suspend.c
CC lib/psci/psci_common.c
CC lib/psci/psci_main.c
CC lib/psci/psci_setup.c
CC lib/psci/psci_system_off.c
CC lib/psci/psci_mem_protect.c
CC lib/locks/bakery/bakery_lock_coherent.c
CC lib/psci/psci_stat.c
CC lib/pmf/pmf_main.c
CC lib/extensions/spe/spe.c
CC lib/extensions/amu/aarch64/amu.c
CC lib/extensions/sve/sve.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
/tmp/ccswitLr.s: Assembler messages:
/tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS plat/arm/board/fvp/aarch64/fvp_helpers.S
AS lib/cpus/aarch64/aem_generic.S
AS lib/cpus/aarch64/cortex_a35.S
AS lib/cpus/aarch64/cortex_a53.S
AS lib/cpus/aarch64/cortex_a57.S
AS lib/cpus/aarch64/cortex_a72.S
AS lib/cpus/aarch64/cortex_a73.S
AS lib/cpus/aarch64/cpuamu_helpers.S
AS bl31/aarch64/bl31_entrypoint.S
AS bl31/aarch64/crash_reporting.S
AS bl31/aarch64/ea_delegate.S
AS bl31/aarch64/runtime_exceptions.S
AS lib/cpus/aarch64/dsu_helpers.S
AS plat/common/aarch64/platform_mp_stack.S
AS lib/el3_runtime/aarch64/cpu_data.S
AS lib/cpus/aarch64/cpu_helpers.S
AS lib/locks/exclusive/aarch64/spinlock.S
AS lib/psci/aarch64/psci_helpers.S
AS lib/el3_runtime/aarch64/context.S
AS lib/extensions/amu/aarch64/amu_helpers.S
AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S
AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl31/bl31.ld.S
LD build/fvp/release/bl31/bl31.elf
BIN build/fvp/release/bl31.bin
Built build/fvp/release/bl31.bin successfully
OD build/fvp/release/bl31/bl31.dump
CC plat/arm/board/fvp/fvp_bl2u_setup.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/delay_timer/delay_timer.c
CC drivers/delay_timer/generic_delay_timer.c
CC plat/arm/common/arm_bl2u_setup.c
CC bl2u/bl2u_main.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS bl2u/aarch64/bl2u_entrypoint.S
AS plat/common/aarch64/platform_up_stack.S
AS common/aarch64/early_exceptions.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl2u/bl2u.ld.S
LD build/fvp/release/bl2u/bl2u.elf
BIN build/fvp/release/bl2u.bin
Built build/fvp/release/bl2u.bin successfully
OD build/fvp/release/bl2u/bl2u.dump
CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts
CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts
CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts
CPP fdts/fvp-base-gicv3-psci.dts
DTC fdts/fvp-base-gicv3-psci.dts
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000:
simple-bus unit address format error, expected "0"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000:
simple-bus unit address format error, expected "200000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000:
simple-bus unit address format error, expected "202000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000:
simple-bus unit address format error, expected "300000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing
or empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or
empty reg/ranges property
--
Best Regards
Masahiro Yamada
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
If I build TF-A with ALLOW_RO_XLAT_TABLES=1,
the base xlat table goes into .rodata section
instead of .bss section.
Then, I see a warning like:
/tmp/ccswitLr.s: Assembler messages:
/tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata
Is this a know issue?
[Reproduce Command]
make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1
The full build log is below:
masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp
CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1
CC lib/libfdt/fdt.c
CC lib/libfdt/fdt_addresses.c
CC lib/libfdt/fdt_empty_tree.c
CC lib/libfdt/fdt_ro.c
CC lib/libfdt/fdt_rw.c
CC lib/libfdt/fdt_strerror.c
CC lib/libfdt/fdt_sw.c
CC lib/libfdt/fdt_wip.c
AR build/fvp/release/lib/libfdt.a
Building fvp
CC lib/libc/abort.c
CC lib/libc/assert.c
CC lib/libc/exit.c
CC lib/libc/memchr.c
CC lib/libc/memcmp.c
CC lib/libc/memcpy.c
CC lib/libc/memmove.c
CC lib/libc/memrchr.c
CC lib/libc/memset.c
CC lib/libc/printf.c
CC lib/libc/putchar.c
CC lib/libc/puts.c
CC lib/libc/snprintf.c
CC lib/libc/strchr.c
CC lib/libc/strcmp.c
CC lib/libc/strlcpy.c
CC lib/libc/strlen.c
CC lib/libc/strncmp.c
CC lib/libc/strnlen.c
CC lib/libc/strrchr.c
AS lib/libc/aarch64/setjmp.S
AR build/fvp/release/lib/libc.a
CC drivers/arm/smmu/smmu_v3.c
CC drivers/arm/sp805/sp805.c
CC drivers/delay_timer/delay_timer.c
CC drivers/io/io_semihosting.c
CC lib/semihosting/semihosting.c
CC plat/arm/board/fvp/fvp_bl1_setup.c
CC plat/arm/board/fvp/fvp_err.c
CC plat/arm/board/fvp/fvp_io_storage.c
CC drivers/arm/cci/cci.c
CC drivers/delay_timer/generic_delay_timer.c
CC drivers/cfi/v2m/v2m_flash.c
CC drivers/io/io_fip.c
CC drivers/io/io_memmap.c
CC drivers/io/io_storage.c
CC plat/arm/common/arm_bl1_setup.c
CC plat/arm/common/arm_err.c
CC plat/arm/common/arm_fconf_io_storage.c
CC plat/arm/common/fconf/arm_fconf_io.c
CC lib/fconf/fconf.c
CC lib/fconf/fconf_dyn_cfg_getter.c
CC plat/arm/common/arm_dyn_cfg.c
CC plat/arm/common/arm_dyn_cfg_helpers.c
CC common/fdt_wrappers.c
CC bl1/bl1_main.c
CC bl1/aarch64/bl1_arch_setup.c
CC bl1/aarch64/bl1_context_mgmt.c
CC lib/cpus/errata_report.c
CC lib/el3_runtime/aarch64/context_mgmt.c
CC plat/common/plat_bl1_common.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS lib/semihosting/aarch64/semihosting_call.S
AS plat/arm/board/fvp/aarch64/fvp_helpers.S
AS lib/cpus/aarch64/aem_generic.S
AS lib/cpus/aarch64/cortex_a35.S
AS lib/cpus/aarch64/cortex_a53.S
AS lib/cpus/aarch64/cortex_a57.S
AS lib/cpus/aarch64/cortex_a72.S
AS lib/cpus/aarch64/cortex_a73.S
AS bl1/aarch64/bl1_entrypoint.S
AS bl1/aarch64/bl1_exceptions.S
AS lib/cpus/aarch64/cpu_helpers.S
AS plat/common/aarch64/platform_up_stack.S
AS lib/cpus/aarch64/dsu_helpers.S
AS lib/el3_runtime/aarch64/context.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl1/bl1.ld.S
LD build/fvp/release/bl1/bl1.elf
BIN build/fvp/release/bl1.bin
Built build/fvp/release/bl1.bin successfully
OD build/fvp/release/bl1/bl1.dump
CC drivers/arm/sp805/sp805.c
CC drivers/io/io_semihosting.c
CC lib/utils/mem_region.c
CC lib/semihosting/semihosting.c
CC plat/arm/board/fvp/fvp_bl2_setup.c
CC plat/arm/board/fvp/fvp_err.c
CC plat/arm/board/fvp/fvp_io_storage.c
CC plat/arm/common/arm_nor_psci_mem_protect.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/cfi/v2m/v2m_flash.c
CC drivers/delay_timer/delay_timer.c
CC drivers/delay_timer/generic_delay_timer.c
CC drivers/io/io_fip.c
CC drivers/io/io_memmap.c
CC drivers/io/io_storage.c
CC plat/arm/common/arm_bl2_setup.c
CC plat/arm/common/arm_err.c
CC plat/arm/common/arm_fconf_io_storage.c
CC plat/arm/common/fconf/arm_fconf_io.c
CC lib/fconf/fconf.c
CC lib/fconf/fconf_dyn_cfg_getter.c
CC plat/arm/common/arm_dyn_cfg.c
CC plat/arm/common/arm_dyn_cfg_helpers.c
CC common/fdt_wrappers.c
CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c
CC plat/arm/common/arm_image_load.c
CC common/desc_image_load.c
CC bl2/bl2_image_load_v2.c
CC bl2/bl2_main.c
CC bl2/aarch64/bl2_arch_setup.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS lib/semihosting/aarch64/semihosting_call.S
AS lib/locks/exclusive/aarch64/spinlock.S
AS plat/common/aarch64/platform_up_stack.S
AS common/aarch64/early_exceptions.S
AS bl2/aarch64/bl2_entrypoint.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl2/bl2.ld.S
LD build/fvp/release/bl2/bl2.elf
BIN build/fvp/release/bl2.bin
Built build/fvp/release/bl2.bin successfully
OD build/fvp/release/bl2/bl2.dump
CC drivers/arm/fvp/fvp_pwrc.c
CC drivers/arm/smmu/smmu_v3.c
CC drivers/delay_timer/delay_timer.c
CC drivers/cfi/v2m/v2m_flash.c
CC lib/utils/mem_region.c
CC plat/arm/board/fvp/fvp_bl31_setup.c
CC plat/arm/board/fvp/fvp_pm.c
CC plat/arm/board/fvp/fvp_topology.c
CC plat/arm/common/arm_nor_psci_mem_protect.c
CC drivers/arm/gic/common/gic_common.c
CC drivers/arm/gic/v3/gicv3_main.c
CC drivers/arm/gic/v3/gicv3_helpers.c
CC plat/common/plat_gicv3.c
CC plat/arm/common/arm_gicv3.c
CC drivers/arm/gic/v3/gic500.c
CC drivers/arm/cci/cci.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/delay_timer/generic_delay_timer.c
CC lib/cpus/aarch64/cpuamu.c
CC plat/arm/common/arm_bl31_setup.c
CC plat/arm/common/arm_pm.c
CC plat/arm/common/arm_topology.c
CC plat/common/plat_psci_common.c
CC plat/arm/common/aarch64/execution_state_switch.c
CC plat/arm/common/arm_sip_svc.c
CC lib/pmf/pmf_smc.c
CC bl31/bl31_main.c
CC bl31/interrupt_mgmt.c
CC bl31/bl31_context_mgmt.c
CC common/runtime_svc.c
CC services/arm_arch_svc/arm_arch_svc_setup.c
CC services/std_svc/std_svc_setup.c
CC lib/el3_runtime/cpu_data_array.c
CC lib/el3_runtime/aarch64/context_mgmt.c
CC lib/cpus/errata_report.c
CC lib/psci/psci_off.c
CC lib/psci/psci_on.c
CC lib/psci/psci_suspend.c
CC lib/psci/psci_common.c
CC lib/psci/psci_main.c
CC lib/psci/psci_setup.c
CC lib/psci/psci_system_off.c
CC lib/psci/psci_mem_protect.c
CC lib/locks/bakery/bakery_lock_coherent.c
CC lib/psci/psci_stat.c
CC lib/pmf/pmf_main.c
CC lib/extensions/spe/spe.c
CC lib/extensions/amu/aarch64/amu.c
CC lib/extensions/sve/sve.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
/tmp/ccswitLr.s: Assembler messages:
/tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS plat/arm/board/fvp/aarch64/fvp_helpers.S
AS lib/cpus/aarch64/aem_generic.S
AS lib/cpus/aarch64/cortex_a35.S
AS lib/cpus/aarch64/cortex_a53.S
AS lib/cpus/aarch64/cortex_a57.S
AS lib/cpus/aarch64/cortex_a72.S
AS lib/cpus/aarch64/cortex_a73.S
AS lib/cpus/aarch64/cpuamu_helpers.S
AS bl31/aarch64/bl31_entrypoint.S
AS bl31/aarch64/crash_reporting.S
AS bl31/aarch64/ea_delegate.S
AS bl31/aarch64/runtime_exceptions.S
AS lib/cpus/aarch64/dsu_helpers.S
AS plat/common/aarch64/platform_mp_stack.S
AS lib/el3_runtime/aarch64/cpu_data.S
AS lib/cpus/aarch64/cpu_helpers.S
AS lib/locks/exclusive/aarch64/spinlock.S
AS lib/psci/aarch64/psci_helpers.S
AS lib/el3_runtime/aarch64/context.S
AS lib/extensions/amu/aarch64/amu_helpers.S
AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S
AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl31/bl31.ld.S
LD build/fvp/release/bl31/bl31.elf
BIN build/fvp/release/bl31.bin
Built build/fvp/release/bl31.bin successfully
OD build/fvp/release/bl31/bl31.dump
CC plat/arm/board/fvp/fvp_bl2u_setup.c
CC drivers/arm/tzc/tzc400.c
CC plat/arm/board/fvp/fvp_security.c
CC plat/arm/common/arm_tzc400.c
CC drivers/delay_timer/delay_timer.c
CC drivers/delay_timer/generic_delay_timer.c
CC plat/arm/common/arm_bl2u_setup.c
CC bl2u/bl2u_main.c
CC common/bl_common.c
CC common/tf_log.c
CC drivers/console/multi_console.c
CC plat/common/plat_bl_common.c
CC plat/common/plat_log_common.c
CC plat/common/aarch64/plat_common.c
CC lib/compiler-rt/builtins/popcountdi2.c
CC lib/compiler-rt/builtins/popcountsi2.c
CC plat/arm/board/fvp/fvp_common.c
CC plat/arm/common/arm_common.c
CC plat/arm/common/arm_console.c
CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
CC lib/xlat_tables_v2/xlat_tables_context.c
CC lib/xlat_tables_v2/xlat_tables_core.c
CC lib/xlat_tables_v2/xlat_tables_utils.c
AS bl2u/aarch64/bl2u_entrypoint.S
AS plat/common/aarch64/platform_up_stack.S
AS common/aarch64/early_exceptions.S
AS common/aarch64/debug.S
AS lib/aarch64/cache_helpers.S
AS lib/aarch64/misc_helpers.S
AS plat/common/aarch64/platform_helpers.S
AS drivers/arm/pl011/aarch64/pl011_console.S
AS plat/arm/board/common/aarch64/board_arm_helpers.S
AS plat/arm/common/aarch64/arm_helpers.S
AS lib/xlat_tables_v2/aarch64/enable_mmu.S
PP bl2u/bl2u.ld.S
LD build/fvp/release/bl2u/bl2u.elf
BIN build/fvp/release/bl2u.bin
Built build/fvp/release/bl2u.bin successfully
OD build/fvp/release/bl2u/bl2u.dump
CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts
CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts
CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts
DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts
CPP fdts/fvp-base-gicv3-psci.dts
DTC fdts/fvp-base-gicv3-psci.dts
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000:
simple-bus unit address format error, expected "0"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000:
simple-bus unit address format error, expected "200000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000:
simple-bus unit address format error, expected "202000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000:
simple-bus unit address format error, expected "300000000"
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5:
Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing
or empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or
empty reg/ranges property
./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6:
Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or
empty reg/ranges property
--
Best Regards
Masahiro Yamada
Hi All,
I’ll be running the TF-A Tech Forum next week and I wanted to give an idea of what to expect in this inaugural meeting.
While in future meetings I will want to seek input of what the agenda will be before the meeting with the option for other project contributors to present on topics in this first one I have a set agenda which is influenced by the format used in the counterpart TF-M Tech Forum.
Agenda:
* Introduction to the TF-A Technical Forum Meeting
* Technical Overview of the Debug-FS Feature
* Optional TF-A Mailing List Topic Discussions
Thanks
Joanna
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Bill Fletcher via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Bill Fletcher <bill.fletcher(a)linaro.org>
Date: Friday, 28 February 2020 at 15:25
To: <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a(a)lists.trustedfirmware.org)
This event has been changed.
TF-A Tech Forum
When
Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time
Calendar
tf-a(a)lists.trustedfirmware.org
Who
(Guest list has been hidden at organiser's request)
more details »<https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY…>
Changed:
We are starting 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. Future invites will be 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…>
Meeting ID: 915 970 4974
One 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-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
(updated due to content filtering issues)
Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY…>
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<https://support.google.com/calendar/answer/37135#forwarding>.
-- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
Hello,
I'm preparing a set of patches for GICv3 driver for GICv3.1 and GICv4 support.
Please review and provide your comments for the 1st patch which separates GICD and GICR accessor functions and adds new macros for GICv3 registers access.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3550
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.
sandeep.tripathy(a)broadcom.com has replied "Maybe" to this invitation.
Title: TF-A Tech Forum
This meeting originally contained an attachment. Please contact your
organizer for the attachment.
This event has been changed.
TF-A Tech Forum
When
Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time
Calendar
tf-a(a)lists.trustedfirmware.org
Who
(Guest list has been hidden at organiser's request)
more details »
Changed:
We are starting 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. Future invites will be 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/
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974
Meeting ID: 915 970 4974
One 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-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h
(updated due to content filtering issues)
Going (tf-a(a)lists.trustedfirmware.org)?
Yes -
Maybe -
No more options »
Invitation from Google 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 .
When: Thu Mar 12, 2020 10:30pm – 11:30pm India Standard Time - Kolkata
Calendar: Bill Fletcher via TF-A
Who:
* Bill Fletcher via TF-A - organizer
* sandeep.tripathy(a)broadcom.com - creator
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 organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
This event has been changed.
Title: TF-A Tech Forum
We are starting 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. Future invites will be 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 (updated due to
content filtering issues) (changed)
When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time
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=MGVhNDdsMGVqNnEzZ3BpY…
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
You have been invited to the following event.
Title: TF-A Tech Forum
We are starting 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. Future invites will be 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: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time
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=MGVhNDdsMGVqNnEzZ3BpY…
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
Hi Scott
Please add the platform specific flags as a field in fip_dev_state_t.
typedef struct {
uintptr_t dev_spec;
uint32_t plat_toc_flag;
} fip_dev_state_t;
Then this field can be updated as part of verifying the FIP header. This header needs to be cleared when the device is closed.
Introduce a helper in fip driver to query the flags:
int fip_dev_get_plat_toc_flag(io_dev_info_t *dev_info, uint32_t *plat_toc_flag);
That should satisfy your requirement.
Best Regards
Soby Mathew
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Scott
> Branden via TF-A
> Sent: 07 February 2020 18:57
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] FIP header flags available for feature selection
>
> Hello,
>
> The fip header has reserved fields available for platform specific use.
> The fiptool allows these header fields to be filled in using the --plat-toc-flags.
>
> A call needs to be available in the ATF framework to get these flags without
> accessing the FIP file again to get these flags.
> We have a solution we've used for ATF for quite some time to access these
> flags.
>
> It's finally being upstreamed here:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839
>
> If there are any other efficient methods to access these flags or a better
> proposal please suggest.
>
> Thanks,
> Scott
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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 Raghu,
Thanks a lot for the review comments and feedback!
On 2/25/20 3:45 AM, Raghu Krishnamurthy via TF-A wrote:
> The patch stack looks great! I do have a suggestion for the long term
> evolution/future work on root's of trust and cert_create. It would be
> great to generalize "dual-root" to "multi-root". It is conceivable that
> firmware supporting secure partitions/SPCI etc, could move to having
> multiple root's of trust. Here we have the silicon provider, and the
> platform owner as two roots, but a more complex system could contain
> silicon firmware, platform firmware and multiple secure partitions, each
> signed by different entities. To remove the signing dependencies between
> each of these entities, we could have a ROTPK for each of these entities
> and the same solution used here, can be applied to solve multiple root's
> of trust and is summarized very well by your statement -"As long as
> there is a defined contract between BL2 and the (P)(*)ROTK-rooted images
> as to how/where to securely get this key or hash, there should not be
> any need for the two vendors to do any cross-signing."
>> To do this, If possible, we should start moving away from tables such as
> the ones in cert_create/src/dualroot/cot.c and have platforms provide
> the certificate dependencies and keys used to sign them in a config
> file. This achieves two things: it makes cert_create independent of the
> cert chain a platform wants to use and the number of roots of trust,
> and, makes cert_create more usable by reducing the number of command
> line arguments to be provided, which is a long list today. You could
> potentially use the config file provided to auto generate the tbbr_cot.c
> file being linked into the firmware too.
>
> Let me know what you think.
I agree with everything you said above. Indeed, there's no reason to
stop at 2 roots of trust and as you pointed out there are real use cases
to enable more. The dualroot chain of trust is only the first step in
that direction and is a useful way to experiment with extending the TBBR
implementation and chain of trust, while addressing a real use case.
Also completely agree with the lack of flexibility of the hard-coded
chain of trust in cert_create/src/dualroot/cot.c and
drivers/auth/dualroot/cot.c for that matter. In fact, we (at Arm) are
thinking along the same lines as you and have had similar ideas boiling
for some time. We are making gradual changes to introduce more
flexibility into TF-A, not just for the chain of trust, but for any
platform-specific data.
Maybe you've seen the recent FConf framework patches, which is a key
piece into enabling platform layers to move platform-specific data into
configuration files. There is still work to do but down the line we are
already thinking about moving the chain of trust description into such a
configuration file.
Moving the CoT into a configuration file has many advantages:
- It could constitute the single input source for the chain of trust,
serving both the cert_create tool and the firmware. Today, the CoT is
described and duplicated in both places and there is really no good
reason to keep things like that IMO. As you said, we could auto-generate
the tbbr_cot.c file and build into the firmware, or even have the
firmware dynamically parse the configuration file at runtime and extract
its CoT.
- It could simplify the description of the CoT. Today, I think that the
C data structures in tbbr_cot.c are quite complex and not
straight-forward to understand at first. If we described them using some
configuration language, I believe we could abstract some of these
details away or at least organize them in a more intuitive way.
Regards,
Sandrine
Hi Sandrine,
The patch stack looks great! I do have a suggestion for the long term
evolution/future work on root's of trust and cert_create. It would be
great to generalize "dual-root" to "multi-root". It is conceivable that
firmware supporting secure partitions/SPCI etc, could move to having
multiple root's of trust. Here we have the silicon provider, and the
platform owner as two roots, but a more complex system could contain
silicon firmware, platform firmware and multiple secure partitions, each
signed by different entities. To remove the signing dependencies between
each of these entities, we could have a ROTPK for each of these entities
and the same solution used here, can be applied to solve multiple root's
of trust and is summarized very well by your statement -"As long as
there is a defined contract between BL2 and the (P)(*)ROTK-rooted images
as to how/where to securely get this key or hash, there should not be
any need for the two vendors to do any cross-signing."
To do this, If possible, we should start moving away from tables such as
the ones in cert_create/src/dualroot/cot.c and have platforms provide
the certificate dependencies and keys used to sign them in a config
file. This achieves two things: it makes cert_create independent of the
cert chain a platform wants to use and the number of roots of trust,
and, makes cert_create more usable by reducing the number of command
line arguments to be provided, which is a long list today. You could
potentially use the config file provided to auto generate the tbbr_cot.c
file being linked into the firmware too.
Let me know what you think.
Thanks
Raghu
On 2/24/20 3:43 AM, Sandrine Bailleux via TF-A wrote:
> Hi,
>
> Following up on my email sent in November 2019:
> https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html
>
> and the proof-of-concept code and documentation shared at that time:
> [1]
> https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/
> [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443
>
> I've made a number of improvements and cleanups in the code. I am
> posting a new version that introduces this new chain of trust (called
> "dualroot", as it has 2 roots of trust) as an alternative to the default
> TBBR one. Right now, it is only enabled on some Arm platforms but it
> should be pretty straight-forward to extend this to other platforms.
>
> The code is available there:
> https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22
>
> and is comprised of the following patches:
> - Introduce a new "dualroot" chain of trust
> - cert_create: Define the dualroot CoT
> - Build system: Changes to drive cert_create for dualroot CoT
> - plat/arm: Provide some PROTK files for development
> - plat/arm: Add support for dualroot CoT
> - plat/arm: Pass cookie argument down to arm_get_rotpk_info()
> - plat/arm: Retrieve the right ROTPK when using the dualroot CoT
>
> This patch stack is based on preparatory work (which has already been
> merged) to select a different CoT. This patch stack:
> - Did some build system refactoring.
> - Introduced a new 'COT' build option to select the chosen chain of trust.
> - Made no functional change.
> See
> http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03…
>
> Note that I've not updated the TF-A documentation just yet to reflect
> these changes. I will do that once I've had some initial feedback from
> the community and feel that we're reaching a consensus (in the interest
> of saving time keeping documentation aligned with code going under rework).
>
>
> Changes Compared to the Proof-of-Concept Patch [2]
> --------------------------------------------------
>
> - Introduced a proper, separate chain of trust rather than hijacking the
> TBBR one. It also has its own header file for certificate extensions
> OIDs now.
>
> - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short.
> Going forward, this key would sign both non-trusted images (such as
> BL33) and secure partitions. The NS- prefix did not fit well this use
> case. The "Platform" prefix instead refers to the owner of this key,
> i.e. the platform owner, as opposed to the Silicon Provider.
>
> - Removed Non-Trusted World Bootloader Key Certificate.
> This didn't seem needed in this context and simplifies the CoT.
>
> - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's
> not used in this CoT (the PROTPK signs all non-trusted images instead).
>
> - As a consequence, the corresponding option for feeding the PROTPK to
> the cert_create tool has been renamed into --prot-key (was --ns-rot-key).
>
> - The hash of the PROTPK is now provided in a file rather than being
> hard-coded into the code. This is cleaner than polluting the code with a
> byte array.
>
> - Proper integration in the build system.
> Using the dualroot chain of trust is achieved through the COT build
> option:
>
> make <usual trusted boot build options> COT=dualroot
>
> - plat_get_rotpk_info() is unchanged if using the TBBR CoT.
> The alternative implementation managing both ROTPK or PROTPK is
> selected only if the dualroot CoT has been chosen at build time.
>
>
> Testing and Supported Platforms
> -------------------------------
>
> Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states),
> rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on
> https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…).
>
> Arm Juno is not supported right now because it has its own
> implementation of plat_get_arm_rotpk_info() instead of piggy-backing on
> the Arm common one.
>
> Ran the standard set of tests available in the TF-A-Tests repository:
> http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
>
> Also ran the firmware update tests available in the same repository. See
>
> https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns…
> for more information.
>
> Finally, performed some end-to-end boot tests to Linux.
>
> And of course, ran our regression tests to make sure that existing
> configurations using the TBBR chain of trust are still working as expected.
>
>
> Caveats
> -------
>
> The PROTPK hash is embedded into the firmware. It's unlikely that a real
> system would like to do that. The use case targeted here is to remove
> the need for the primary ROTPK owner to interact with the PROTPK owner.
> If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner
> (which is expected to be the primary ROTPK owner) has to get the PROTPK
> from the other vendor.
>
> In a real system, we would expect the PROTPK to be provisioned in such a
> way that BL2 is able to retrieve it. For example, the PROTPK owner might
> burn it (or a hash of it) in some OTP memory. As long as there is a
> defined contract between BL2 and the PROTK-rooted images as to how/where
> to securely get this key or hash, there should not be any need for the
> two vendors to do any cross-signing.
>
> This caveat was already present in the proof-of-concept [2] and stays
> out of the scope for this work, as this ties into broader topics such as
> key provisioning. Right now, the onus is on the platform layer to handle
> this appropriately.
>
>
> Future work
> -----------
>
> We have plans to change the "dualroot" CoT further and extend the PROTPK
> signing domain with a secure partition. This would demonstrate the use
> of several secure partitions, some owned by the silicon provider, others
> owned by the platform owner.
>
>
> Regards,
> Sandrine
>