- TF-A - lists.trustedfirmware.org

by IS20 Boaz Baron

Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn't defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, 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.

5 years

1
0
0 0

Secure boot without FIP

by guillaume pivetta

Hi, I’m trying to implement a secure boot on a STM32MP1 without using the FIP file. For now , I am not able to use FIP format during the boot process so I use a depreciated boot process with TF-Av2.2 as FSBL and U-Boot as SSBL to boot my Board. My boot process do Romcode -> TF-A (BL2) -> SP_min (BL32) -> U-Boot (BL33) -> Linux kernel I succefully implemented signature authentification between U-Boot and Linux image, but between TF-A and U-Boot it’s a little bit harder. I learned on ST wiki how to sign my u-boot binary with the STM32MP_SigningTool_CLI, but when I sign my binary with a custom private key, TF-A don’t authentified it on boot, even if i tryed to pass my key to TF-A at compilation time with the BL33_KEY argument, which i think is dedicated to the FIP usage. I found, in the sources of TF-A, what I think being a developpement key, named « arm_rotpk_ecdsa.pem ». And when I sign my binary with this key, I am able to perform the signature check and continu my boot process. So I tryed to change this key with a custom one and recompile TF-A to update the key in the final binary, but it seem that it is not so simple. I found yesterday that the auth_mod_init() function wasn’t call because I had forgotten the TUSTED_BOARD_BOOT=1 compilation argument. But when I activate it, the compilation doesn’t work and i see « build/arm-trusted-firmware-v2.2/bl2/bl2_main.c:91: undefined reference to `auth_mod_init' » Whitch traditionnaly append when linker don’t find the .o where the functions are implemented. I would like to know if it is possible to implement some kind of authentification with custom keys without FIP and if yes where can i find some hints/ressources/tutorial ? I don’t find a lot of ressources about secure boot without FIP so I hope you will be able to help me.

5 years

1
0
0 0

Re: [TF-A] Please provide option to build with GICv3 for qemu

by Jens Wiklander

Hi Alexey, On Thu, Jul 22, 2021 at 10:14 AM Alexey Kazantsev via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hello! > > Please add a build option for selecting GICv3 instead of GICv2 for QEMU > platform. > > There is the following line in plat/qemu/qemu/platform.mk : > QEMU_USE_GIC_DRIVER := QEMU_GICV2 > > It doesn't imply setting GICv3 externally by build system of other > projects, like OP-TEE. When building with OP-TEE we're overriding this assignment by passing "QEMU_USE_GIC_DRIVER=$(TFA_GIC_DRIVER)" (where TFA_GIC_DRIVER is either QEMU_GICV3 or QEMU_GICV2) on the command line. This is now tested on a regular basis since we've recently added Xen support to the OP-TEE build setup on QEMU V8 and this depends on using GICv3 instead of GICv2. Does this help in your case? Cheers, Jens

5 years

2
1
0 0

Please provide option to build with GICv3 for qemu

by Alexey Kazantsev

Hello! Please add a build option for selecting GICv3 instead of GICv2 for QEMU platform. There is the following line in plat/qemu/qemu/platform.mk : QEMU_USE_GIC_DRIVER := QEMU_GICV2 It doesn't imply setting GICv3 externally by build system of other projects, like OP-TEE. Best regards, Aleksey.

5 years

1
0
0 0

Re: [TF-A] [RFC] QTI platform ports violate Binary Components policy?

by Julius Werner

Hi Tom, Thanks for your interest in the SC7180 TF-A port! You're asking fair questions about a difficult situation, so let me try to add some background: The binary component policy was actually written specifically as part of the discussions about adding the SC7180 port, to lay some guidelines and ground rules about how to deal with binary components (which already existed in some other platform ports beforehand). This case was discussed in-depth with the project leaders and the trustedfirmware.org Board beforehand, and it was always understood that this would have to be a tricky compromise. As you may know, devices (e.g. Android phones) with Qualcomm chipsets generally do not run TF-A, but instead run Qualcomm's proprietary trusted OS and secure monitor (QTEE). The TF-A port was more of an experimental side project (which has by now resulted in a few SC7180-based Chromebooks being sold with TF-A, but the much larger phone market continues to use QTEE), so unfortunately the TF project's position to make demands is not yet as solid as you may think. Basically, we could have either made these compromises or continue to not support Qualcomm chipsets at all, so due to their prevalence in the ecosystem we decided it would be worth it to start like this, try to make the situation as good as it can get, and then hopefully improve on that in future chipset generations. The binary policy is meant as more of a decision guideline and individual cases are ultimately up to the Board. FWIW maybe I slightly mis-summarized the policy in the text added to the contributing.rst document -- I think saying that the *majority* of the platform port (in terms of bytes of code) should be open source, while a good ambition in general, was never realistic for SC7180. The full document in https://git.trustedfirmware.org/tf-binaries.git/tree/readme.rst instead says "Binary components that contain all meaningful functionality of a platform port" are not accepted -- the intention is that there are pieces large enough to be worth modifying in the open source part, while allowing vendors to keep functionality proprietary that they absolutely do not want (or are not allowed) to disclose. For SC7180, things like UART, SPMI, PMIC and RNG drivers as well as SMC validation are implemented in open source (and as you noticed some of those were ported piecemeal at later points of the development process). I'll be the first to admit that this isn't a lot and we absolutely want to do more, but it is a tricky and very time-consuming process both in identifying the exact parts that can be open-sourced without IP concerns and then actually doing the work (since the qtiseclib code is still proprietary even if there is a Linux driver for the same subsystem, we can't just copy things over, it has to be carefully rewritten and revalidated). The state you see the SC7180 port in right now is basically just as far as we got over the course of this project (and believe me it took a lot of effort already, even if it may not look like much). Hopefully we can make further progress with the next chipset. Also, just as a note, we didn't actually end up hosting qtiseclib in the TF binary repository in the end, due to concerns about details in the license text that couldn't be resolved. It is instead hosted by the coreboot.org project at the moment. I'm not sure if this technically means that the TF binary component policy applies to this blob or not (from a strict reading of the text I would say it doesn't), but that's not really that relevant... like I said, in the end the Board makes final decisions about whether a platform port is accepted into the repository or not on a case by case basis, and the policy is just a general guideline. The general goal is to make sure the TF-A ports are actually useful to open source developers while allowing for pragmatic compromises in tricky situations like this, and in this case we decided that allowing this port would be more useful than not (although it's certainly on the edge). On Tue, Jul 20, 2021 at 2:05 AM Tom Johnsen <tomjohnsen(a)protonmail.com> wrote: > > Hello! > > I recently discovered the TF-A port for QTI SC7180 and was very happy > to see this. I always thought it would have been great if Qualcomm made > (open-source) TF-A ports for their platforms. For example, I would be > interested in TF-A for the DragonBoard 820c (APQ8096E). > Unfortunately, after talking to some other people I have been told > it is unlikely that Qualcomm will ever have this. :-/ > > I am not much of a firmware developer but I was curious so I wanted to > check how much SoC-specific code is actually needed for a TF-A port. At > first I was surprised - the QTI platform ports seem fairly simple, there > is not much SoC-specific code at all. However, it looks like the reason for > that is that almost all of the SoC-specific code is actually contained in a > proprietary "qtiseclib" blob that is statically linked into the bl31.bin. > > I did not really expect to see something like that in a public > open-source project, especially not one as security-critical as TF-A. > It looks like some binary components are indeed allowed as per the > Contribution Guidelines (1). Yet, after reading them and looking at the > code again I wonder how the amount of functionality implemented > in the "qtiseclib" could really conform to these guidelines? > > I quote them here (from (1)) for convenience: > > > Binary components must be restricted to only the specific > > functionality that cannot be open-sourced and must be linked into a > > larger open-source platform port. The majority of the platform port > > must still be implemented in open source. Platform ports that are > > merely a thin wrapper around a binary component that contains all the > > actual code will not be accepted. > > There are two main reasons why I do not think that the "qtiseclib" > conforms to these guidelines. > > --- 1. "Majority of the platform port must be open-source" --- > > I have built TF-A for QTI SC7180 according to the documentation (2). > The resulting bl31.bin has a size of 182088 bytes. The linker conveniently > produces a "bl31.map" file that shows exactly which part of the binary > comes from which component of the TF-A port. It can be analyzed easily, > for example with fpv-gcc (3). > > The following table shows the distribution of the bl31.bin: > > +-------------+----------+-----+ > | Component | Size (B) | % | > +-------------+----------+-----+ > | libqtisec.a | 147344 | 81% | > | Other BL31 | 23838 | 13% | > | plat/qti | 5222 | 3% | > | Padding | 3863 | 2% | > | libc.a | 1821 | 1% | > +-------------+----------+-----+ > > Clearly, the libqtisec.a dominates with 81%. The open-source part of the > QTI TF-A platform port (plat/qti) is merely 3% of the final binary. > > Perhaps it is just large static data tables? The following table shows > only the distribution of .text symbols (excluding libc and "Other BL31"): > > +-------------+----------+-----+ > | Component | Size (B) | % | > +-------------+----------+-----+ > | libqtisec.a | 75792 | 95% | > | plat/qti | 3920 | 5% | > +-------------+----------+-----+ > > I do not see any way to interpret this as "the majority of the platform > port is open-source". It is hard to find any substantial functionality > that does not end up calling into the proprietary qtiseclib. In my > opinion, the port is hardly more than "a thin wrapper around a binary > component" which is explicitly forbidden in the guidelines. > > --- 2. "Binary components should be as minimal as possible" --- > > It is hard to judge this given that the license for "qtiseclib" (obviously) > does not allow reverse-engineering. However, just judging from some of the > symbol names that I see visibly in the "bl31.map" Qualcomm seems to have > spent little effort to keep the binary component actually minimal. > > "qtiseclib" also contains code for IP blocks that have public > open-source drivers in Linux, including for: > > - TLMM (GPIO) > - GCC (Clocks) > - rpmh > > Perhaps some "secret" registers are programmed there but it is hard to > believe that there is no overlap that could have been made open-source. > > This is also quite visible based on changes that were made later. > The PRNG and SPMI driver were moved out of "qtiseclib" later (4, 5) > and both can be found similarly in Linux. > > --- Conclusion --- > > How does this conform to the Binary Components policy that is part of > the contribution guidelines? Was this not checked during review? > > All in all I cannot help but get the feeling that Qualcomm has fairly > little interest to have open-source firmware. Not even simple hardware > initialization that probably exists similarly in open-source drivers > has been implemented in open-source code. The resulting bl31.bin can > be hardly called "open-source" when 81% of it is actually proprietary. > > If this is intended and considered acceptable I suggest rewriting the > "Binary Components" policy to explicitly allow vendors to require > any amount of proprietary code for their TF-A ports. Personally, I think > this is a very bad idea though and just encourages all other vendors to > do the same in the future. TF-A (as a trusted reference implementation) > is in a good position to make certain demands that must be met for > inclusion in the upstream tree. > > I am mainly sad about this because this certainly means that only > Qualcomm can make such ports by providing the "qtiseclib" that contains > most of the functionality. Perhaps open-source code could have been > adjusted by the community to other platforms with some effort. > > Thanks for reading. > ~ Tom > > (1) https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… > (2) https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti.html > (3) https://github.com/ebs-universe/fpv-gcc > (4) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4885 > (5) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4409

5 years

1
0
0 0

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

by Julius Werner

> > Thank you all for your feedback. > > It appears that in theory we are all happy with using bloblist with few > implementation details which needs to be taken care of during > implementation. > Just to clarify: are you using "bloblist" as a general term for the concept of a simple linked list of tagged data blobs, or to refer specifically to the U-Boot implementation with that name? The existing TF-A implementation (bl_aux_params) is basically identical in concept to the U-Boot bloblist, but not binary compatible. Are we talking about just keeping that, or throwing it away in order to reimplement the exact structure U-Boot is using? (I would prefer to keep the bl_aux_params as they are to avoid disrupting existing uses, of course. Making backwards-incompatible changes to an interface that passes across multiple repos and firmware components is always a big pain.)

5 years

5
9
0 0

FIP and FCONF for STM32MP1

by Yann Gautier

Hi everyone, I've just pushed a series to support FIP and FCONF on STM32MP1 platform. I haven't put any TF-A maintainers yet, but feel free to comment. Just be aware that I'll be out of office for the 3 and a half coming weeks, so I won't be able to push new patch sets. But I'll try to connect from time to time to answer questions, if any. Best regards, Yann

5 years, 1 month

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jul 15, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling the TF-A Tech forum this week as the majority of attendees have clashing events and cannot join." 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 Jul 15, 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

5 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 371992: Control flow issues (DEADCODE) /plat/qemu/common/qemu_pm.c: 116 in qemu_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 371992: Control flow issues (DEADCODE) /plat/qemu/common/qemu_pm.c: 116 in qemu_validate_ns_entrypoint() 110 /* 111 * Check if the non secure entrypoint lies within the non 112 * secure DRAM. 113 */ 114 if ((entrypoint >= NS_DRAM0_BASE) && 115 (entrypoint < (NS_DRAM0_BASE + NS_DRAM0_SIZE))) >>> CID 371992: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 0;". 116 return PSCI_E_SUCCESS; 117 return PSCI_E_INVALID_ADDRESS; 118 } 119 120 /******************************************************************************* 121 * Platform handler called when a CPU is about to enter standby. ** CID 371991: Control flow issues (NO_EFFECT) /plat/qemu/common/qemu_pm.c: 115 in qemu_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 371991: Control flow issues (NO_EFFECT) /plat/qemu/common/qemu_pm.c: 115 in qemu_validate_ns_entrypoint() 109 { 110 /* 111 * Check if the non secure entrypoint lies within the non 112 * secure DRAM. 113 */ 114 if ((entrypoint >= NS_DRAM0_BASE) && >>> CID 371991: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "entrypoint < 0UL". 115 (entrypoint < (NS_DRAM0_BASE + NS_DRAM0_SIZE))) 116 return PSCI_E_SUCCESS; 117 return PSCI_E_INVALID_ADDRESS; 118 } 119 120 /******************************************************************************* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8195/plat_pm.c: 298 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8195/plat_pm.c: 298 in plat_validate_power_state() 292 { 293 unsigned int pstate = psci_get_pstate_type(power_state); 294 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 295 unsigned int cpu = plat_my_core_pos(); 296 297 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 298 return PSCI_E_INVALID_PARAMS; 299 } 300 301 if (pstate == PSTATE_TYPE_STANDBY) { 302 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 303 } else { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A