Hi all,
I want to add some big data structures in BL31 (e.g., create a large
uint32_t array). Also, I reserve a secure memory space (assume it is
0xa000_0000 - 0xb000_0000) by configuring TZASC.
Now, the BL31 says
build/fvp/debug/bl31/bl31.elf section `.bss' will not fit in region `RAM'
aarch64-none-elf-ld: BL31 image has exceeded its limit.
aarch64-none-elf-ld: region `RAM' overflowed by 458752 bytes
It looks like that the previous RAM cannot hold my big data
structures. If I want to add my reserved region into RAM (so I may
allocate these data into the reserved region), what should I do?
Sincerely,
Wang
Hi,
Please allow me to add some more details. Also posting to the TF-A list, as all tf.org repositories are affected.
The root cause of this issue is OpenSSH dropping support for SHA-1 RSA signatures with the 8.8 release, and thus any OS (or git client) coming with a recent version is affected. I.e. the newest git for windows is affected too, and so are “top notch” Linux distributions like Arch.
For details see the “Potentially-incompatible changes” chapter here: https://www.openssh.com/releasenotes.html
As the above page states “Incompatibility is more likely when connecting to older SSH implementations…”, and thus a server-side update would eliminate the problem. Till that happens the page above list multiple client-side workarounds. (It is possible to amend the ssh config in a way that fixes all repositories.)
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: December 15, 2021 13:06
To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Tip on cloning TF-M on OS X Monterey
I recently switched to a new MBP that ships with OS X Monterey, and on both 12.0 and 12.1 (released this week) git clone seems to be broken when you're using HTTP rather than SSH:
digital envelope routines:CRYPTO_internal:bad key length
In order to clone TF-M, I had to make the following changes.
1. Add these details to $HOME/.ssh/config (microbuilder being my github username, associated with my TF-M account):
Host trustedfirmware.org<http://trustedfirmware.org>
User microbuilder
Hostname review.trustedfirmware.org<http://review.trustedfirmware.org>
Port 29418
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
2. Then try to clone with:
$ git clone trustedfirmware.org:/TF-M/trusted-firmware-m.git
This fails, however, since it tries to clone tf-m-tests.git, so:
3. Edit lib/ext/tf-m-tests/fetch_repo.cmake, changing:
FetchContent_Declare(tfm_test_repo
GIT_REPOSITORY trustedfirmware.org:TF-M/tf-m-tests.git
# GIT_REPOSITORY https://git.trustedfirmware.org/TF-M/tf-m-tests.git
GIT_TAG ${TFM_TEST_REPO_VERSION}
GIT_PROGRESS TRUE
)
This let me at least clone TF-M until the issues with HTTP-based cloning are fixed.
Hope this is useful to someone else working on OS X natively.
Kevin
Hi,
On STM32MP1, we'd like BL2 to be agnostic of what BL32 is in the FIP.
It can be either OP-TEE or TF-A SP_min.
But on STM32MP1, SP_min needs a device tree file (TOS_FW_CONFIG_ID),
whereas OP-TEE doesn't use this separate DT image.
As TOS_FW_CONFIG_ID is in list of images to be loaded by BL2, we then
have a warning message in case OP-TEE is used:
WARNING: FCONF: Invalid config id 26
I'd like to silence this warning with this kind of patch:
diff --git a/lib/fconf/fconf_dyn_cfg_getter.c
b/lib/fconf/fconf_dyn_cfg_getter.c
index 25dd7f9eda..f7e9834c3b 100644
--- a/lib/fconf/fconf_dyn_cfg_getter.c
+++ b/lib/fconf/fconf_dyn_cfg_getter.c
@@ -51,7 +51,11 @@ struct dyn_cfg_dtb_info_t
*dyn_cfg_dtb_info_getter(unsigned int config_id)
}
}
- WARN("FCONF: Invalid config id %u\n", config_id);
+ if (config_id == TOS_FW_CONFIG_ID) {
+ VERBOSE("FCONF: No TOS_FW_CONFIG image\n");
+ } else {
+ WARN("FCONF: Invalid config id %u\n", config_id);
+ }
return NULL;
}
I can change the VERBOSE message to INFO.
Do you think it is OK if I push the patch?
Thanks,
Yann
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…