I’m not sure if the cancellations have been sent from the trustedfirmware.org calendar system so confirming that they are cancelled to the list.
Next scheduled Tech Forum is 13th January 2022.
Joanna
Hi all,
I want to load a specific image in BL31. But when I call
load_auth_image(). It says
"in function `load_image':
trusted-firmware-a/common/bl_common.c:87: undefined reference to
`plat_get_image_source'"
Also, the io_read, io_size and etc. are undefined reference.
I find other BL files (bl1, bl2) will call the load_auth_image() in
their main functions or sub-functions. If I want to implement it on
BL31, what should I do? Should I modify the Makefile?
Sincerely,
Wang
Hi all,
We are pleased to announce the formal release of Trusted Firmware-A version 2.6, Trusted Firmware-A Tests version 2.6, Hafnium version 2.6 and TF-A OpenCI Scripts 2.6 Releases involving the tagging of multiple sub repositories.
These went live on 24th November 2021.
Notable Features of the Version 2.6 Release across repositories are as follows:
* v8-R64 Upstream support, trusted-boot (BL1) only
* RME patches (4 world support)
* Hunter & Hayes CPU support
* Demeter (Makalu ELP for Infra) CPU support
* ARM v9.0-A ETE V1.0
* ARM v9.1-A ETE V1.1
* Armv9 RME support
* Generic Firmware Update support
* Measured Boot Enhancements
* MPMM AMU support SME (Mortlach) for non-secure world (FEAT_SME)
* Security hardening LLVM/clang support.
* FF-A v1.1 notifications support.
* FF-A v1.1 interrupt handling support.
* S-EL0 partitions (through VHE in the secure world).
* SPM support for saving/restoring the normal world SVE live state.
* Build system update to LLVM/Clang 12.
* Updates to FF-A Setup and discovery.
* FF-A compliance fixes.
* Threat model introduced for SPMC at SEL2
* Eight new partner and Arm platforms support added
Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes the previous release.
The test plan and results [4] for the v2.6 release captures the release test activities.
TF-A [5], TF-A Test [6], Hafnium [7] and TF-A OpenCI Scripts [8] repositories are available
[1] https://trustedfirmware-a.readthedocs.io/en/v2.6/
[2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…
[3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.6/
[4] https://confluence.arm.com/display/BSGSoftware/TF-A+v2.6+Test+Plan+and+Resu…
[5] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6
[6] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.6
[7] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.6
[8] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.6
Thanks & best regards,
[cid:image001.jpg@01D7E120.C34F0DA0]
Bipin Ravi | Principal Design Engineer
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
Hi.
I'm trying to run on our new platform Linux as BL33, preloaded to DDR.
currently simulated over QEMU.
I think that BL31 started BL33 in EL0, which cause problems:
QEMU outputs this message: (complete log below)
Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000
What could I have done wrong in the configuration that caused it ?
What should I check ?
Thanks !
Ramon.
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.5(debug):v2.5-61-g84d7d6a30-dirty
NOTICE: BL1: Built : 14:53:02, Nov 21 2021
INFO: BL1: RAM 0x15500000 - 0x15513000
WARNING: BL1: neoverse_n1: CPU workaround for 1946160 was missing!
INFO: BL1: Loading BL2
INFO: Using mmap
INFO: Using FIP
INFO: Loading image id=1 at address 0x14300000
INFO: Image id=1 loaded: 0x14300000 - 0x143052d1
INFO: bl1_mem_layout->total_base = 0x14000000x
NOTICE: BL1: Booting BL2
INFO: Entry point address = 0x14300000
INFO: SPSR = 0x3c5
Exception return from AArch64 EL3 to AArch64 EL1 PC 0x14300000
INFO: BL1 inherited memory layout: 0x14000000 [size = 22020096]
NOTICE: BL2: v2.5(debug):v2.5-61-g84d7d6a30-dirty
NOTICE: BL2: Built : 14:53:02, Nov 21 2021
INFO: BL2: Skip loading image id 23
INFO: BL2: Doing platform setup
INFO: BL2: Loading image id 3
INFO: Using mmap
INFO: Using FIP
INFO: Loading image id=3 at address 0x800000000
INFO: Image id=3 loaded: 0x800000000 - 0x8000080a9
INFO: BL2: Skip loading image id 5
Taking exception 13 [Secure Monitor Call]
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0x14302a04
...to EL3 PC 0x5400 PSTATE 0x3cd
NOTICE: BL1: Booting BL31
INFO: Entry point address = 0x800000000
INFO: SPSR = 0x3cd
Exception return from AArch64 EL3 to AArch64 EL3 PC 0x800000000
INFO: Boot BL33 from 0x800080000 for 0 Bytes
NOTICE: BL31: v2.5(debug):v2.5-61-g84d7d6a30-dirty
NOTICE: BL31: Built : 14:53:04, Nov 21 2021
INFO: GICv3 without legacy support detected.
INFO: ARM GICv3 driver initialized in EL3
INFO: Maximum SPI INTID supported: 63
INFO: BL31: Initializing runtime services
WARNING: BL31: neoverse_n1: CPU workaround for 1946160 was missing!
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x800080000
INFO: SPSR = 0x0
Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000
Taking exception 1 [Undefined Instruction]
...from EL0 to EL1
...with ESR 0x18/0x6232c061
...with ELR 0x8000b7164
...to EL1 PC 0x400 PSTATE 0x3c5
Taking exception 4 [Data Abort]
This event has been canceled with this note:
"Cancelling TF-A Tech Forum this week as the team have nothing to present.
We expect to have a topic for December 2nd."
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: Thu Nov 18, 2021 4pm – 5pm United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher - creator
* marek.bykowski(a)gmail.com
* okash.khawaja(a)gmail.com
* tf-a(a)lists.trustedfirmware.org
Invitation from Google Calendar: https://calendar.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://calendar.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
Hi Pali,
My understanding of the errata reporting mechanism is that some erratas are always checked during CPU boot. If the corresponding MACRO (ERRATA_A53_*) is disabled, then the ERRATA_MISSING code is reported.
I would be concerned if the CPU is affected by the errata. If the errata needs to be enabled, the fix would be to enable the ERRATA_A53_* from the platform makefile.
Hope this helps.
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pali Rohár via TF-A
Sent: Wednesday, July 7, 2021 9:11 PM
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Bipin Ravi <Bipin.Ravi(a)arm.com>; tf-a(a)lists.trustedfirmware.org
Cc: Konstantin Porotchkin <kostap(a)marvell.com>; Marek Behún <marek.behun(a)nic.cz>
Subject: Re: [TF-A] Missing CPU workaround warning message
External email: Use caution opening links or attachments
Hello! Could somebody from TF-A helps with these two topics? I would really need to know if "missing errata warnings" debug message is some critical and needs to be fixed (and how?) or it is just a debug message and therefore should not be a warning...
On Monday 28 June 2021 17:11:18 Pali Rohár wrote:
> On Monday 28 June 2021 14:03:06 Olivier Deprez wrote:
> > Hi,
> >
> > Is the question strictly related to this platform not implementing the mentioned errata (for which a platform change can be emitted)?
>
> Hello! The first question is if this is an issue that CPU workaround
> is missing. And if yes (which seems to be) how big issue it is? And
> how to resolve it?
>
> > Or is it more generally that those "missing errata warnings" are not printed in release mode?
> > Assuming the latter, it looks to me it is the integrator mistake to not include the appropriate mitigations at development phase (hence while using debug mode for building TF-A).
> > Then when the device is deployed (hence most often built for release mode), if this message is printed it is an indication for a malicious agent that such attack vector through mis-implemented errata is possible. So the consequence is possibly even worst than just "missing" to include the errata.
> >
> > Other TF-Aers (Bipin?) may have other opinions?
>
> And this is a second question. If missing CPU workaround is an issue,
> should not be it printed also in release build?
>
> Also I see that in release builds are omitted not only messages about
> missing CPU workarounds, but basically _all_ warning messages. But
> notice messages are _not_ omitted. Which seems strange as in most
> cases notice message has lower priority than warning message.
>
> >
> > Regards,
> > Olivier.
> >
> > ________________________________________
> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of
> > Pali Rohár via TF-A <tf-a(a)lists.trustedfirmware.org>
> > Sent: 28 June 2021 15:36
> > To: tf-a(a)lists.trustedfirmware.org
> > Cc: Konstantin Porotchkin; Marek Behún
> > Subject: [TF-A] Missing CPU workaround warning message
> >
> > Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug
> > mode then at runtime it prints following warning messages:
> >
> > WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing!
> > WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing!
> >
> > These lines are not printed in non-debug mode. It is an issue?
> > --
> > TF-A mailing list
> > TF-A(a)lists.trustedfirmware.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > sts.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01
> > %7Cvwadekar%40nvidia.com%7Cb3605175f552468740e708d941836783%7C43083d
> > 15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612854914595696%7CUnknown%7C
> > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VCI6Mn0%3D%7C1000&sdata=%2FW6HuFPYQCD5ECIA%2FZZxhm5ti5HYILNlsWTz
> > moJ7L8E%3D&reserved=0
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
<Adding TF-A mailing list to the discussion>
Thanks, Soby. I agree that this needs to be re-evaluated for platforms. I think we should introduce an option to disable them, if required.
We plan to try some more experiments and hopefully remove the locks at least for Tegra platforms.
Looking forward to the elaborate answer.
From: Soby Mathew <Soby.Mathew(a)arm.com>
Sent: Tuesday, 2 November 2021 10:18 AM
To: Varun Wadekar <vwadekar(a)nvidia.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Dan Handley <Dan.Handley(a)arm.com>
Cc: Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>
Subject: RE: PSCI lock contention
External email: Use caution opening links or attachments
Hi Varun,
The short answer is that the locks are used to differentiate the last-CPU-to-suspend and similarly first-CPU-to-powerup at a given power domain level. Now, recent CPU features like DynamIQ means that we don't need to do this differentiation upto cluster level which TF-A hasn't optimized for yet AFAICS. I am happy to elaborate further , but could you please send the query to the TF-A mailing list as I would prefer this discussion to happen in the open if possible.
Best Regards
Soby Mathew
From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>
Sent: 01 November 2021 20:14
To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>>
Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>
Subject: PSCI lock contention
Hi,
We were trying performance benchmarking for CPU_SUSPEND on Tegra platforms. We take all CPU cores to CPU_SUSPEND and then wake them up with IPI - all at once and in serial order. From the numbers, we see that the CPUs powering up later take more time than the first one. We have narrowed the most time consumed to the PSCI locks - documented at docs/perf/psci-performance-juno.rst.
Can you please help me understand why these locks were added? As a quick experiment we tried the same benchmarking *without* the locks and the firmware does not blow up, but I would like to understand the impact from the analysis on Juno (docs/perf/psci-performance-juno.rst)
Happy to hop on a call to discuss further.
Thanks.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
TF-A Community,
Just a reminder we are looking to freeze the tree for release activities starting Monday.
Thanks
Joanna
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Joanna Farley <Joanna.Farley(a)arm.com>
Date: Monday, 1 November 2021 at 12:41
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Trusted Firmware-A v2.6 release activities in November
TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories.
Essentially we will not merge any major enhancements from this date until the release is made.
Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021.
Any major enhancement patches still open after that date will not be merged until after the release.
This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start.
Thanks
Joanna
This event has been canceled with this note:
"No TF-A Tech Forum scheduled this week so cancelling."
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: Thu Nov 4, 2021 4pm – 5pm United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher - creator
* marek.bykowski(a)gmail.com
* okash.khawaja(a)gmail.com
* tf-a(a)lists.trustedfirmware.org
Invitation from Google Calendar: https://calendar.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://calendar.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
Forwarded on to TF-A Mail list. Seems postings from people with gmail.com email domains get automatically rejected, sorry Ramon not sure if that can be addressed.
Joanna
On 03/11/2021, 14:20, "Ramon Fried" <rfried.dev(a)gmail.com> wrote:
Hi.
I'm trying to run the example in TF-A documentation.
I found two problems.
First, the files: "tee-header_v2.bin, tee-pager_v2.bin,
tee-pageable_v2.bin" are not provided as binary downloads, and
instructions on how to get them are missing. turn's out you need to
build optee, but this step is skipped if you choose to download the
QEMU_EFI.fd from Linaro.
Second,
after following the instructions step by step resulted in the following error:
qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57
-kernel Image -no-acpi -append
'console=ttyAMA0,38400 keep_bootcon' -initrd rootfs.cpio.gz -smp
2 -m 1024 -bios flash.bin -d unimp
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.5(release):v2.5-60-g7737fdf0e
NOTICE: BL1: Built : 13:12:39, Nov 3 2021
NOTICE: BL1: Booting BL2
NOTICE: BL2: v2.5(release):v2.5-60-g7737fdf0e
NOTICE: BL2: Built : 13:12:42, Nov 3 2021
NOTICE: BL1: Booting BL31
NOTICE: BL31: v2.5(release):v2.5-60-g7737fdf0e
NOTICE: BL31: Built : 13:12:45, Nov 3 2021
read access to unsupported AArch64 system register op0:3 op1:0 crn:12
crm:12 op2:4
This occurs on Qemu 5.0 and also 6.0
Thanks,
Ramon.
TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories.
Essentially we will not merge any major enhancements from this date until the release is made.
Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021.
Any major enhancement patches still open after that date will not be merged until after the release.
This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start.
Thanks
Joanna
Hi all,
What is the resolution for secure memory space with the Trust zone?
Is it dependent on the MMU resolution? Means, for example, If my MMU can set a range of 16 KB so can I set that range as a trusted zone as well?
P.S. I have ARM A35 (I am not sure but I think my MMU supports a resolution of 32KB)
You are welcome to comment if I have any mistakes
Thanks a lot,
Boaz.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
I want to know if we have a chance to support the compiler-based CFI(eg clang cfi, kernel support it.) function in tf-a.
I want to know that is anyone doing this, or if everyone is interested in this?
Cheers,
Feng
Hi HPChen
1. Can try setting PLATFORM_MAX_AFFLVL to MPIDR_AFFLVL2? I am assuming your platform has 1 cluster with 2 cores.
2. The project currently supports a limited number of platforms. The default test suite[1] contains several smaller test suites. The tests are designed to auto-detect critical features supported by the platform. Rather than fail, tftf will skip tests if a feature is not supported.
Please refer to the documentation for the tf-a-tests project here: https://trustedfirmware-a-tests.readthedocs.io/en/latest/index.html
[1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/tests-s…
Thanks,
Madhukar
-----Original Message-----
From: TF-A <mailman-bounces(a)lists.trustedfirmware.org> On Behalf Of MS10 HPChen0
Sent: Tuesday, October 12, 2021 10:43 PM
To: tf-a-owner(a)lists.trustedfirmware.org
Subject: TFA affinity power level
Hi,
I'm Nuvoton software engineer. We have an A35 dual core platform. I ported the TFA for this platform.
Now I want test the TFA on test suite. I have some questions. Please help to answer. Thanks!
1. If define 'PLATFORM_MAX_AFFLVL' to MPIDR_AFFLVL1. The tftf test only identify single core no matter 'PLATFORM_CORES_PER_CLUSTER' define to 2.
How should I define 'PLATFORM_MAX_AFFLVL'?
2. How to select the test items? Should our platform need to pass all test items? Now I only test the tftf.
I'm new for TFA. Please help. Thanks!
Best regards,
HPChen
________________________________
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
I noticed TF-A currently supports passing in 4 parameters and returning
up to 8. But SMCCC 1.1+ supports passing up to 18 and returning 18 in
AArch64 mode, and passing in/out 8 in AArch32.
I was wondering if there are any plans to add support for handling the
full set of parameters?
--
Rebecca Cran
Hi
I'm new to TF-A and OP Tee.
While I am using qemu to start TF-A, I got BL1 detected and failed to load
BL2, due to BL2 size out of bounds.
I changed TF-A BL1 source code to show more information:
diff --git a/common/bl_common.c b/common/bl_common.c
index 2fcb5385d9..a6239a5257 100644
--- a/common/bl_common.c
+++ b/common/bl_common.c
@@ -110,7 +111,7 @@ static int load_image(unsigned int image_id,
image_info_t *image_data)
/* Check that the image size to load is within limit */
if (image_size > image_data->image_max_size) {
- WARN("Image id=%u size out of bounds\n", image_id);
+ WARN("Image id=%u size(%lu, %u) out of bounds\n", image_id,
image_size, image_data->image_max_size);
io_result = -EFBIG;
goto exit;
}
the log shows:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.3():v2.3-dirty
NOTICE: BL1: Built : 15:56:43, Apr 20 2020
INFO: BL1: RAM 0xe04e000 - 0xe056000
VERBOSE: BL1: cortex_a57: CPU workaround for 806969 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 813419 was missing!
VERBOSE: BL1: cortex_a57: CPU workaround for 813420 was not applied
VERBOSE: BL1: cortex_a57: CPU workaround for 814670 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 817169 was missing!
INFO: BL1: cortex_a57: CPU workaround for disable_ldnp_overread was
applied
WARNING: BL1: cortex_a57: CPU workaround for 826974 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 826977 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 828024 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 829520 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 833471 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 859972 was missing!
INFO: BL1: cortex_a57: CPU workaround for cve_2017_5715 was applied
INFO: BL1: cortex_a57: CPU workaround for cve_2018_3639 was applied
INFO: BL1: Loading BL2
VERBOSE: Using Memmap
WARNING: Firmware Image Package header check failed.
VERBOSE: Trying alternative IO
VERBOSE: Using Semi-hosting IO
INFO: Loading image id=1 at address 0xe01b000
WARNING: Image id=1 size(4294967295, 151552) out of bounds
ERROR: Failed to load BL2 firmware.
I'm using yocto (dunfell) + meta-arm to build / test TF-A + OP TEE under
qemuarm64.
meta-arm rev: c4f04f3fb66f8f4365b08b553af8206372e90a63
variables defined inside conf/local.conf ( for test )
23 MACHINE ?= "qemuarm64"
25
26 INSANE_SKIP_pn-optee-examples = "ldflags"
27 COMPATIBLE_MACHINE_pn-optee-examples = "qemuarm64"
28 COMPATIBLE_MACHINE_pn-optee-os = "qemuarm64"
29 COMPATIBLE_MACHINE_pn-optee-client = "qemuarm64"
30 COMPATIBLE_MACHINE_pn-trusted-firmware-a = "qemuarm64"
31
32 TFA_PLATFORM = "qemu"
33 TFA_UBOOT = "1"
34 TFA_DEBUG = "1"
35 TFA_SPD = "opteed"
36 TFA_BUILD_TARGET = "bl1 bl2 bl31"
37
38 OPTEEMACHINE:qemuarm64 = "vexpress-qemu_armv8a"
39 OPTEEOUTPUTMACHINE:qemuarm64 = "vexpress"
40
41 UBOOT_MACHINE_qemuarm64 = "qemu_arm64_defconfig"
I started qemu using following command line:
BIOS=tmp/deploy/images/qemuarm64/bl1.bin \
KERNEL=tmp/deploy/images/qemuarm64/Image-qemuarm64.bin \
runqemu mydefined-image-core-image-dev-optee nographic -d \
qemuparams=" \
-machine secure=on \
-m 4096 \
-d unimp -semihosting -semihosting-config enable=on,target=native \
"
Thanks
Hi all,
We made a few changes to the UFS driver. The proposed patches are posted
here:
https://review.trustedfirmware.org/q/topic:%22ufs_patches%22+(status:open%2…
.
The patches mainly consist of the below changes:
1. Delete asserts. Return error values instead.
2. Add retry logic and timeouts.
3. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands.
Any feedback/comments on these patches would be greatly appreciated.
Thanks!
Jorge Troncoso
+ TF-A ML (for the benefit of other trying to use firmware encryption
feature)
Hi Promod,
On Fri, 8 Oct 2021 at 00:09, pramod kumar <pramod.jnumca04(a)gmail.com> wrote:
> Hi Sumit,
>
> This is Pramod, Presently working in Amazon Lab126. I'm working in ATF and
> was going through your patch which provides f/w image encryption/decryption
> support.
>
> commit 7cda17bb0f92db39d123a4f2a1732c9978556453
> Author: Sumit Garg <sumit.garg(a)linaro.org>
> Date: Fri Nov 15 10:43:00 2019 +0530
>
> drivers: crypto: Add authenticated decryption framework
>
> Add framework for autheticated decryption of data. Currently this
> patch optionally imports mbedtls library as a backend if build option
> "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated
> decryption
> using AES-GCM algorithm.
>
> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org>
> Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
>
> I see that this support comes under DECRYPTION_SUPPORT macro hence can't
> be used dynamically. I see the TBBR spec provides a flag for this which
> could be used to exercise this feature dynamically-
> [image: image.png]
>
>
> Just wanted to understand that did you see any limitation to use this flag
> for making this feature support dynamically? Or do you have any plan to
> push follow up patches for this?
>
>
Actually there are security concerns associated if we use an unsigned
encryption flag in the header (see earlier discussions [1]).
> If this feature is made available, with the help of "disable_auth" flag,
> BL1 would be able to boot plane images even when TRUSTED_BOARD_BOOT is
> enabled in development mode.
>
I agree here that it would be useful to have such a flag in development
mode. For TRUSTED_BOARD_BOOT in development mode, I guess you are referring
to DYN_DISABLE_AUTH. If yes then I think such a macro makes sense for
encryption as well in order to disable decryption at runtime in development
mode, patches are very much welcome.
[1]
https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000288.html
-Sumit
> Regards,
> Pramod
>
Hi All,
We have refactored/redesigned the existing measured boot driver present in the TF-A repo to support it with multiple backend driver(s) (for example, TCG Event Log, physical TPM, etc) instead of it being strongly coupled with the TCG Event Log driver.
Proposed refactored patches are posted here: https://review.trustedfirmware.org/q/topic:%22refactor-mb%22+(status:open%2…
Any feedback/comments on these patches are much appreciated.
These patches mainly consist of the below changes:
1. Move image measurement in the generic layer, just after loading and authentication of the image. Previously, the platform layer was responsible for the measurement. For example, the Arm FVP platform layer was doing it as part of the post-load hook operation.
2. Measurement and recording of the images loaded by BL1. Previously, DTB config files loaded by BL1 were not part of measured at all. Also, it looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event log buffer/physical TPM/any other TPM backend instead of deferring these recordings to BL2.
3. Pass Event Log buffer information from BL1 to BL2 so that the TCG Event Log buffer initialised by BL1 extended further with the measurements taken by BL2.
Note: These patches neither add any new functional backend driver for measured boot nor update any existing backend driver functionality (i.e. TCG Event Log driver). These changes only structured the measured boot code to provide a space to plug in any new backend driver(s) in future for the measured boot.
Thanks,
Manish Badarkhe
This event has been canceled with this note:
"Cancelling this weeks TF-A Tech Forum as we have no subjects/topics to
present for this meeting.
The TF-A project community is always looking for subjects/topics so if you
have something to present/discuss please do reach out to me and we can
schedule a session.
Thanks all."
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: Thu Oct 7, 2021 4pm – 5pm United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher - creator
* marek.bykowski(a)gmail.com
* okash.khawaja(a)gmail.com
* tf-a(a)lists.trustedfirmware.org
Invitation from Google Calendar: https://calendar.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://calendar.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
Hi all,
I tried submitting a change for review at https://review.trustedfirmware.org,
but I ran into authentication issues.
1. First try (https):
$ git push origin HEAD:refs/for/integration
Username for 'https://review.trustedfirmware.org': jatron
Password for 'https://jatron@review.trustedfirmware.org':
remote: Unauthorized
fatal: Authentication failed for '
https://review.trustedfirmware.org/TF-A/trusted-firmware-a/'
I tried clicking "GENERATE NEW PASSWORD" in
https://review.trustedfirmware.org/settings/, but I got the following
error message:
An error occurred
Error 500 (Server Error): Internal server error
Endpoint: /accounts/self/password.http
2. Second try (ssh):
I got the following error message when I tried registering a new SSH key
for use with Gerrit. This happened when I clicked "ADD NEW SSH KEY" in
https://review.trustedfirmware.org/settings/.
An error occurred
Error 500 (Server Error): Internal server error
Endpoint: /accounts/self/sshkeys
The error message didn't stop the GUI from recording my key though. My new
key was listed under "SSH keys" after the change. When I ran a git push
command using ssh, I got the following error.
$ git push ssh://jatron@review.trustedfirmware.org/TF-A/trusted-firmware-a
HEAD:refs/for/integration
jatron(a)review.trustedfirmware.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Am I doing something incorrectly? Any help would be much appreciated. If
this is not the mailing list for these types of questions, please let me
know so I can reroute my email to the proper destination.
Thanks,
Jorge Troncoso