- TF-A - lists.trustedfirmware.org

rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

by Christoph Fritz

Hello Kever, on a rk3399, booting current U-Boot SPL with mainline TF-A leads to missing DMA (and no sound) on Linux. However, when using rockchip its so called mini-loader (rk3399_miniloader_v1.26.bin) and their BL31 (rk3399_bl31_v1.35.elf) to boot, DMA works perfectly fine. Tested on a custom rk3399 board and on ROCK Pi4. Attached to this mail are two boot logs with some debug prints: - good_amba_log.txt (DMA works) - no_amba_log.txt (no DMA device) The main difference I can spot between the two logs is that on Linux (drivers/amba/bus.c) AMBA_CID (0xb105f00d) cannot be found. Instead, only some CORESIGHT_CIDs (presumably for debugging) and four 0x00000000 CIDs are detected. As a result, the "PL330 DMAC-241330" driver does not load. My theory is that DMA needs to be allowed somewhere in the undocumented syscon- registers, similar to what U-Boot is already doing for eMMC in arch_cpu_init() (arch/arm/mach-rockchip/rk3399/rk3399.c). Any ideas? Or maybe I'm just missing some configuration? Since multiple software projects are involved (TF-A, OP-TEE, U-Boot, Linux), I Cc'ed a bit. Thanks -- Christoph

2 years, 2 months

3
4
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics this week so cancelling." TF-A Tech Forum Thursday Apr 6, 2023 ⋅ 4pm – 5pm United Kingdom Time 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   Guests 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 email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 2 months

1
0
0 0

TF-A TechForum 6th April

by Joanna Farley

Hi Folks, I’ve just updated the Techforum session information (Slides and Recording) from the RAS Handing session last week on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ which will be deployed soon once the patch is approved. The next TF-A Tech forum is due on Thursday 6th April at 4pm BST. At this time I don’t have any topics for that session. If anybody in the community has anything they would like to present please do reach out to me. Thanks Joanna

2 years, 2 months

1
0
0 0

Workaround for ARM Cortex-A78AE Erratum 1941500 is not enabled

by matthias.rosenfelder＠nio.io

Hi, according to the current erratum document for the ARM Cortex-A78AE [0], the workaround for erratum 1941500 says: "This erratum can be avoided by setting CPUECTLR_EL1[8] to 1." However, the current code on branch "master" (git hash 5906d97a832b6f6 ) at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… executes a "bic" instruction with an immediate, which is a synthetic instruction to clear the bit, instead of setting it. Moreover, the comment above says "Set bit 8 in ECTLR_EL1", which is inconsistent to the code. The equivalent workaround for the Cortex-A78 non-AE (erratum 1941498) uses the correct "orr" (bitwise-or) instruction to set the bit: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… Please confirm if this is an error. Thank you. Best Regards, Matthias [0] "Arm Cortex-A78AE (MP105) Software Developer Errata Notice", Document version: v14.0, Document ID: SDEN-1707912, https://developer.arm.com/documentation/SDEN1707912/latest

2 years, 2 months

1
0
0 0

Question about configuring Juno R2 GPU SMMU in TF-A

by Chenxu Wang

Hi all, I try to enable the smmu of Juno R2 development board but face two great challenges. I am working on them and I still need some hints. Here are my problems: 1. By reading the SMMUv1 manuals I find that several registers are related to secure state (e.g., SMMU_sCR0). But in my TF-A and the latest version I can only find the SMMUv3 configurations, not SMMUv1/2. Thus, how to config these registers? Any reference? 2. For the non-secure GPU SMMU regs, I try to map and read them based on the Juno R2 manual. I know the GPU SMMU is a MMU-400, and its mmio is in 0x2b40_0000 - 0x2b40_ffff. Then in EL1 I first do ioremap(0x2b400000,0x10000) and then ioread32(). However I get the SError as "Bad mode in Error handler detected on CPU1, code 0xbf000002". I also try to do it in EL2 (with a hvc call and reading in the handler), but cannot get any valid number and still get SError when exiting EL2. But when I access the other smmus (e.g., a PCIe SMMU, in 0x2b50_0000), it works fine. Thus, is there something to prevent the Non-secure World from accessing the GPU SMMU MMIO? My source codes are downloaded from the arm-reference-platforms, in which Linux is v4.14.59 and TF-A is v2.1. Can someone help me? Sincerely, WANG Chenxu

2 years, 2 months

1
1
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Mar 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Updated agenda" Changed: description TF-A Tech Forum Thursday Mar 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Discussion Topic: RAS Refactoring Presented by: Manish Pandey and Soby MathewTopics to be discussed 1. Introduction to philosophies of handling RAS errors(FFH/KFH) 2. Discussing exceptions caused by synchronization barriers at execption boundries 3. Refactoring and enhancements in TF-A(along with various build macros) 4. Tests introduced 5. Future work----------------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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org bpeckham(a)google.com moritzf(a)google.com kh3195(a)columbia.edu View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 2 months

1
0
0 0

About Unmask the SError in serror_aarch64

by Ming Huang

Hi Jeenu, vector_entry serror_aarch64 + msr daifclr, #DAIF_ABT_BIT Why the SError must be unmask in serror_arrch64? We found unmask SError will lead TF-A panic with output "Unhandled Exception in EL3". --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 109.883159] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 109.891195] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 109.896776] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 110.068410] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 110.076988] igb 0000:b1:00.0: enabling device (0000 -> 0002) Unhandled Exception in EL3. x30 = 0x00000000ff013b84 x0 = 0x0000000000000000 x1 = 0xffff800011e7500c x2 = 0x0000000000000000 x3 = 0xffff800011e75004 x4 = 0xffff800011a82000 x5 = 0x000000000000000c x6 = 0x00000000000000fb x7 = 0xffff800011441e80 x8 = 0x0000000000000000 x9 = 0xffff800010655270 x10 = 0x00000000ffff8000 x11 = 0xffff800011701e80 x12 = 0x0000000000000001 x13 = 0xffff800010c08cc0 x14 = 0x0000000000000c80 x15 = 0x0000000000000001 x16 = 0x67692070552f6e77 x17 = 0x7228206465726f6e x18 = 0x0000000000000030 x19 = 0xffff04000032de80 x20 = 0xffff04000032dea0 x21 = 0xffff040002c2f000 x22 = 0xffff000809280000 x23 = 0xffff00080a217800 x24 = 0xffff800011853f80 x25 = 0xffff040002c2e0c8 x26 = 0xffff800011923de8 x27 = 0xffff000817fc8740 x28 = 0x0000000000000000 x29 = 0xffff80001e9ebb00 scr_el3 = 0x000000000403073d sctlr_el3 = 0x0000000030cd183f cptr_el3 = 0x0000000000000100 tcr_el3 = 0x0000000080843514 daif = 0x00000000000003c0 mair_el3 = 0x00000000004404ff spsr_el3 = 0x00000000624002cd elr_el3 = 0x00000000ff013d84 ttbr0_el3 = 0x00000000ff093001 esr_el3 = 0x00000000be000011 far_el3 = 0x7abce97e90b5fee1 spsr_el1 = 0x0000000000000000 elr_el1 = 0x0000000000000000 spsr_abt = 0x0000000000000000 spsr_und = 0x0000000000000000 spsr_irq = 0x0000000000000000 spsr_fiq = 0x0000000000000000 sctlr_el1 = 0x0000000030d00800 actlr_el1 = 0x0000000000000000 cpacr_el1 = 0x0000000000000000 csselr_el1 = 0x0000000000000002 sp_el1 = 0x0000000000000000 esr_el1 = 0x0000000000000000 ttbr0_el1 = 0x0000000000000000 ttbr1_el1 = 0x0000000000000000 mair_el1 = 0x0000000000000000 amair_el1 = 0x0000000000000000 tcr_el1 = 0x0000000000000000 tpidr_el1 = 0xffff800f6e6f1000 tpidr_el0 = 0x00000000f6e1ede0 tpidrro_el0 = 0x0000000000000000 par_el1 = 0xff000000f4214b80 mpidr_el1 = 0x0000000081000000 afsr0_el1 = 0x0000000000000000 afsr1_el1 = 0x0000000000000000 contextidr_el1 = 0x0000000000000000 vbar_el1 = 0x0000000000000000 cntp_ctl_el0 = 0x0000000000000000 cntp_cval_el0 = 0x000000010b938e04 cntv_ctl_el0 = 0x0000000000000000 cntv_cval_el0 = 0x0000000000000000 cntkctl_el1 = 0x0000000000000000 sp_el0 = 0xffff000809280000 isr_el1 = 0x0000000000000040 cpupwrctlr_el1 = 0x0000000000000000 -------------------------------------------------------------------------------------- Remove the above line(mask SError), TF-A continue execute with some useful output. --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 278.193642] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 278.201680] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 278.207262] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 278.378416] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 278.386993] igb 0000:b1:00.0: enabling device (0000 -> 0002) ERROR: Excepton received on 0x81000000, spsr_el3:82401009,reason:0 esr_el3:0xbe000411 ue_cnt:0x0 Exception Class = 2f: SError interrupt. Print cpu register: |-elr_el3: ffff8000106550f8 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 403073d |-sctlr_el3: 30cd183f |-LR: ffff800010655270 |-SP: ffff0008091d1200 |-x0: 0000000000000000 x1: ffff800011e7500c |-x2: 0000000000000000 x3: ffff800011e75004 |-x4: ffff800011a82000 x5: 000000000000000c |-x6: 00000000000000fb x7: ffff800011441e80 |-x8: 0000000000000000 x9: ffff800010655270 |-x10: 00000000ffff8000 x11: ffff800011701e80 |-x12: 0000000000000001 x13: ffff800010c08cc0 |-x14: 0000000000000c80 x15: 0000000000000001 |-x16: 67692070552f6e77 x17: 7228206465726f6e |-x18: 0000000000000030 x19: ffff040005a7e100 |-x20: ffff040005a7e120 x21: ffff040001e9f000 |-x22: ffff0008091d1200 x23: ffff000809cdf800 |-x24: ffff800011853f80 x25: ffff040001e9e0c8 |-x26: ffff800011923de8 x27: ffff000807549140 |-x28: 0000000000000000 x29: ffff80001cc9bb00 INFO: mpidr:81000000, stop s-wtd. Return to lower EL by SDEI ->Core[0](0x81000000) received intr=0(exception), cnt=0x1 RTC: 2023-03-08 10:15:38 ERROR: Excepton received on 0x81000000, spsr_el3:620003c5,reason:2 esr_el3:0x80000011 ue_cnt:0x0 Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: |-elr_el3: ff01a430 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 4000e3c |-sctlr_el3: 30cd183f |-LR: ff208570 |-SP: ff631d80 |-x0: 00000000c4000061 x1: 0000000000000000 |-x2: 0000000000000000 x3: 0000000000000000 |-x4: 0000000000000000 x5: 0000000000000000 |-x6: 0000000000000000 x7: 0000000000000000 |-x8: 0000000000000000 x9: 0000000000000002 |-x10: 0000000000000002 x11: 0000000000000000 |-x12: 0000000000000002 x13: 0000000000000002 |-x14: 0000000000000001 x15: 00000000000000ff |-x16: 00000000ffa97650 x17: 00000000000000f8 |-x18: 0000000000000000 x19: 0000000000000001 |-x20: 0000000000000000 x21: 00000000ff20c240 |-x22: 00000000ff20c25a x23: 8000000000000009 |-x24: 0000000076726473 x25: 00000000ff20d1e0 |-x26: 00000000ffbdcc10 x27: 00000000ff631ef8 |-x28: 00000000ffbff328 x29: 00000000ff631d80 INFO: mpidr:81000000, stop s-wtd. Have report fatal Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: -------------------------------------------------------------------------------------- Regards, Ming

2 years, 2 months

3
4
0 0

commit to tf-a-ci-scripts

by Ruth Glushkin

I have already created patch in tf-a for review, added plat Nuvoton npcm845x, gerrit topic No. 20088. How should I upload a scripts patch to support new added platform? In documentation I didn't found how exactly should I send a scripts patch. Thank you in advance. Margarita Glushkin

2 years, 2 months

3
5
0 0

adding Nuvoton npcm845x platform

by Ruth Glushkin

Commit No: 71b6e2217052057744a1dedaef1c540f3c98e703 feat(plat): added support to Nuvoton npcm845x chip Please review. Margarita Glushkin

2 years, 2 months

2
1
0 0

RFE: GIC workaround for NVIDIA erratum T241-FABRIC-4

by Varun Wadekar

Hi, I would like to get some feedback on the gicv3 workaround [1] for NVIDIA erratum T241-FABRIC-4. The commit description describes the erratum and the fix in detail. The patch is only to start a dialogue and gather feedback on the way forward. Please advise. Thanks. [1] fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4 (I04e33ba6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19969>

2 years, 2 months

1
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, I have another two other questions about this issue. (1) What should I do if the current optee to load already exists or I want to update optee? The most straightforward way I could think of is to reclaim the memory currently used by optee, then reload the optee image and initialize it. (2) optee may use multiple cores. When and how to process the initialization of multiple cores? Do you have any solutions or ideas? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月11日(星期六) 21:44 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Re: Post-boot loading of OP-TEE Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

2 years, 2 months

2
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

2 years, 2 months

1
0
0 0

Errata ABI Design and Implementation

by Sona Rebecca Mathew

Hi all, I presented the Errata ABI design and Implementation in this week's tech forum; the patches are available for review, and any feedback, discussions are welcome. Link to the patch : feat(errata_abi): errata management firmware interface (I70f0e256) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19835> The team would like to merge this feature by the end of March, kindly help review and provide feedback. Thanks -Sona

2 years, 2 months

1
0
0 0

Errata framework proposal

by Boyan Karatotev

Hi all, As presented on this week's tech forum, I have recently been working on a framework to improve errata implementations, consolidate the disparate requirements around them, and make errata information available at runtime. This is related, but separate to the errata ABI which is being worked on by Sona. Patches are available for review [1] and feedback is welcome. This email is to host discussion around the proposal, especially things that came up during the tech forum. The team would like to merge this sometime in April, but the sooner it is accepted, the sooner we can start (and complete!) the migration. [1]: https://review.trustedfirmware.org/q/topic:%22bk%252Ferrata_refactor%22+

2 years, 2 months

1
0
0 0

About kdump hang issue in SDEI dispatch

by Ming Huang

Hi James & TF-A guys, When hest acpi table configure Hardware Error Notification type as Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with TF-A by SDEI mechanism. On the firmware first system, kernel was notified by TF-A sdei call. The calling flow like as below when fatal RAS error happens: TF-A notify kernel flow: sdei_dispatch_event() ehf_activate_priority() call sdei callback // callback registered by kerenl ehf_deactivate_priority() Kernel sdei callback: sdei_asm_handler() __sdei_handler() _sdei_handler() sdei_event_handler() ghes_sdei_critical_callback() ghes_in_nmi_queue_one_entry() /* if RAS error is fatal */ __ghes_panic() panic() If fatal RAS error occured, panic was called in sdei_asm_handle() without ehf_deactivate_priority executed, which lead interrupt masked. If interrupt masked, system would be halted in kdump flow like this: arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting... So interrupt should be restored before panic otherwise kdump will hang. In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME) call should be called before panic for a completed run of ehf_deactivate_priority(). The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80). The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called. This will bring about two issue: 1 Kdump will hang for firmware reporting fatal RAS event by SDEI; (as explain above) 2 For NMI scene，TF-A enable a secure timer, the PPI 29 will trigger periodically. Kernel register a callback for hard lockup. The below code will not be called when panic in kernel callback: TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler(): /* * We reach here when client completes the event. * * If the cause of dispatch originally interrupted the Secure world, * resume Secure. * * No need to save the Non-secure context ahead of a world switch: the * Non-secure context was fully saved before dispatch, and has been * returned to its pre-dispatch state. */ if (sec_state == SECURE) restore_and_resume_secure_context(); /* * The event was dispatched after receiving SDEI interrupt. With * the event handling completed, EOI the corresponding * interrupt. */ if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) { ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num); panic(); } plat_ic_end_of_interrupt(intr_raw); How to fix above issues? I think the root cause is that kernel broken the SDEI dispatch flow, so kernel should modify to fix these issues. Thanks, Ming

2 years, 3 months

4
10
0 0

Need to activate MEASURE_BOOT on nxp ls1043 platform

by Benoit Sansoni

Hello, I am working on a board based on NXP LS1043 processor (arm64) with TPM2 on SPI interface. I have the following boot sequence : TF-A + UBOOT + YOCTO. I have a look on the code where the TF-A MEASURE_BOOT was implemented for the fvp arm platform using OPTEE fTPM. As far as I understood, the event log is implemented based on the TCG2 EFI PROTOCOL from commit : commit 3ee148d6439b69d326f8e6d2a4ce822604e0e64c Merge: 43f7d8879 4a135bc33 Author: joanna.farley <joanna.farley(a)arm.com> Date: Wed Jul 22 16:35:11 2020 +0000 Nevertheless, I am surprised because I did not find any TPM2 driver in the current TF-A code. I would like to know : 1. How to port what was done for the fvp platform to my platform ? 2. What is code hashed in the TFA to create the event log ? 3. Why are there no TPM2 routine in the TF-A to expend PCR ? Thanks in advance for your help Benoit

2 years, 3 months

2
1
0 0

PSCI OS-initiated mode

by Wing Li

Hi, The PSCI specification defines two different power state coordination modes for CPU_SUSPEND that can be used to put a core or a group of cores into a low-power state. These modes are the platform-coordinated mode (default) and the OS-initiated mode (optional). OS-initiated mode is currently not supported by TF-A, while both modes are supported by the Linux Kernel. Requesting reviews for the patches [1] adding support for OS-initiated mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and comments are much appreciated. Thanks in advance! Wing [1] https://review.trustedfirmware.org/q/topic:psci-osi

2 years, 3 months

8
18
0 0

u-boot image for MACCHIATObin Single Shot builds but won't boot

by Maciej Sieczka

Hello, I'm a noob here, and I need help. I've just built flash-image.bin for my MACCHIATObin Single Shot as follows, but it fails to boot - as follows further below: - git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git - Clone the binaries-marvell and mv-ddr-marvell Git repos alongside the trusted-firmware-a, and check out revisions as recommeded in TF-A build instructions for Armada80x0 (https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/buil…). - export CROSS_COMPILE=/my/path/to/arm-gnu-toolchain/11.3.rel1-x86_64-aarch64-none-elf/bin/aarch64-none-elf- - Build u-boot.bin: - git clone https://source.denx.de/u-boot/u-boot.git alongside the binaries-marvell and mv-ddr-marvell repos. - cd u-boot - git checkout v2023.01 - the latest release. - make mvebu_mcbin-88f8040_defconfig - Change CONFIG_DEFAULT_DEVICE_TREE to "armada-8040-mcbin-singleshot" (inspired by this SolidRun doc: https://github.com/SolidRun/documentation/blob/bsp/8040/u-boot.md). - Add arch/arm/dts/armada-8040-mcbin-singleshot.dts. Can be obtained e.g. from the latest Marvell kernel sources (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/). - make - Built fine. - Build TF-A: - cd ../trusted-firmware-a/ - git checkout v2.8.0 - the latest release, as per changelog (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html). - make PLAT=a80x0_mcbin MV_DDR_PATH=../mv-ddr-marvell SCP_BL2=../binaries-marvell/mrvl_scp_bl2.img BL33=../u-boot/u-boot.bin mrvl_flash - Built fine. Then I flashed the flash-image.bin onto my SD card: dd if=trusted-firmware-a/build/a80x0_mcbin/release/flash-image.bin of=/dev/mmcblk0 seek=4096 conv=fdatasync,notrunc (as per https://archlinuxarm.org/platforms/armv8/marvell/macchiatobin). It boots, but complains about a missing serial driver and resets in a loop: --- BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) Found valid image at boot postion 0x002 lNOTICE: Starting binary extension NOTICE: SVC: DEV ID: 8040, FREQ Mode: 0xd NOTICE: SVC: AVS work point changed from 0x29 to 0x29 mv_ddr: devel-g541616b (Mar 05 2023 - 14:15:32) mv_ddr: completed successfully NOTICE: Cold boot NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.8(release):v2.8 NOTICE: BL1: Built : 14:15:45, Mar 5 2023 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.8(release):v2.8 NOTICE: BL2: Built : 14:15:48, Mar 5 2023 NOTICE: SCP_BL2 contains 7 concatenated images NOTICE: Load image to CP1 MG NOTICE: Loading MG image from address 0x402305c Size 0xe0f0 to MG at 0xf4100000 NOTICE: Load image to CP0 MG NOTICE: Loading MG image from address 0x403114c Size 0xe0f0 to MG at 0xf2100000 NOTICE: Skipping MSS CP3 related image NOTICE: Skipping MSS CP2 related image NOTICE: Load image to CP1 MSS AP0 NOTICE: SECURELY Loading MSS FW from addr. 0x4042c34 Size 0x1cfc to MSS at 0xf4280000 NOTICE: CP MSS startup is postponed NOTICE: Done NOTICE: Load image to CP0 MSS AP0 NOTICE: SECURELY Loading MSS FW from addr. 0x4044930 Size 0x1cfc to MSS at 0xf2280000 NOTICE: CP MSS startup is postponed NOTICE: Done NOTICE: Load image to AP0 MSS NOTICE: Loading MSS FW from addr. 0x404662c Size 0x5400 to MSS at 0xf0580000 NOTICE: Done NOTICE: SCP Image doesn't contain PM firmware NOTICE: BL1: Booting BL31 lNOTICE: Starting CP0 MSS CPU NOTICE: Starting CP1 MSS CPU NOTICE: MSS PM is not supported in this build NOTICE: BL31: v2.8(release):v2.8 NOTICE: BL31: Built : 14:15:55, Mar 5 2023 <debug_uart> No serial driver found resetting ... --- Can anyone advise how to fix this? Is this list even the right place to ask such questions? Maciej -- Maciej Sieczka http://www.sieczka.org

2 years, 3 months

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 383288: (CHECKED_RETURN) /mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod() /mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod() ________________________________________________________________________________________________________ *** CID 383288: (CHECKED_RETURN) /mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod() 1664 * 1665 * To achieve this, we make a copy of X and we use the table entry in each 1666 * calculation from this point on. 1667 */ 1668 const size_t x_index = 0; 1669 mbedtls_mpi_init( &W[x_index] ); >>> CID 383288: (CHECKED_RETURN) >>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times). 1670 mbedtls_mpi_copy( &W[x_index], X ); 1671 1672 j = N->n + 1; 1673 /* All W[i] and X must have at least N->n limbs for the mpi_montmul() 1674 * and mpi_montred() calls later. Here we ensure that W[1] and X are 1675 * large enough, and later we'll grow other W[i] to the same length. /mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod() 1861 MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &W[x_index], N, &W[x_index] ) ); 1862 } 1863 1864 /* 1865 * Load the result in the output variable. 1866 */ >>> CID 383288: (CHECKED_RETURN) >>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times). 1867 mbedtls_mpi_copy( X, &W[x_index] ); 1868 1869 cleanup: 1870 1871 /* The first bit of the sliding window is always 1 and therefore the first 1872 * half of the table was unused. */ ** CID 383287: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 383287: Null pointer dereferences (FORWARD_NULL) /mbedtls/library/rsa_alt_helpers.c: 134 in mbedtls_rsa_deduce_primes() 128 129 for( ; attempt < num_primes; ++attempt ) 130 { 131 mbedtls_mpi_lset( &K, primes[attempt] ); 132 133 /* Check if gcd(K,N) = 1 */ >>> CID 383287: Null pointer dereferences (FORWARD_NULL) >>> Passing "P" to "mbedtls_mpi_gcd", which dereferences null "P->p". 134 MBEDTLS_MPI_CHK( mbedtls_mpi_gcd( P, &K, N ) ); 135 if( mbedtls_mpi_cmp_int( P, 1 ) != 0 ) 136 continue; 137 138 /* Go through K^T + 1, K^(2T) + 1, K^(4T) + 1, ... 139 * and check whether they have nontrivial GCD with N. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 3 months

1
0
0 0

[PATCH] fix(mmc): remove redundant reset_to_idle call

by Baruch Siach

mmc_enumerate() is the only caller of mmc_send_op_cond(). mmc_enumerate() calls mmc_reset_to_idle() just before calling mmc_send_op_cond(). No need to do that again in mmc_send_op_cond(). Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Ib8c8ed1a559e3fecb315245f91bb3dc1f547d820 --- Sending the patch to the list once again. review.trustedfirmware.org does not work for me. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- drivers/mmc/mmc.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 2b727d4e7696..57f47482013a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -452,11 +452,6 @@ static int mmc_send_op_cond(void) int ret, n; unsigned int resp_data[4]; - ret = mmc_reset_to_idle(); - if (ret != 0) { - return ret; - } - for (n = 0; n < SEND_OP_COND_MAX_RETRIES; n++) { ret = mmc_send_cmd(MMC_CMD(1), OCR_SECTOR_MODE | OCR_VDD_MIN_2V7 | OCR_VDD_MIN_1V7, -- 2.39.2

2 years, 3 months

2
1
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Rescheduling the 2&4 world RAS architectural changes discussion.More details nearer the event.----------------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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 9, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Changing this session for Errata ABI and Errata Framework discussions.A more detailed agenda will be issued closer to the event.---------------------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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org Michal Simek don.harbin(a)linaro.org ulf.hansson(a)linaro.org moritzf(a)google.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Is NS_BL1U necessary to do FWU ?

by Jun.Chen(陳奕昕)

Hi, In ARM TBBR, there is a requirement “R0100_TBBR_AFM_FLASHING” (The AP firmware must switch to the Non-Trusted world for executing the SoC firmware loader), But there is no requirement for secure boot as long as I finish chain if ROT verification. So, can I implement FWU in BL2 which is verified and load from BL1 (ROM)? For example, BL1(ROM) -> Load and verify BL2U with new image from SD to secure RAM -> execute BL2U in Secure RAM then write new image to NAND flash Best regards, Jun

2 years, 3 months

2
3
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 9, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Reserving this session for a TF-A RAS support update in an evolving Arm architecture.A more detailed agenda will be issued closer to the event.---------------------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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 8am - 9am (PST) (tf-a@lists.trustedfirmware.org)

by wingers＠google.com

This event has been updated Changed: location TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 8am – 9am Pacific Time - Los Angeles Location US-MTV-1015-1-S-Silicon (2) [GVC, Phone] https://www.google.com/maps/search/US-MTV-1015-1-S-Silicon+(2)+%5BGVC,+Phon… Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks AllJoanna===============================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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(a)linaro.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks AllJoanna===============================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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(a)linaro.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Checking SIP Service Calls range

by Michal Simek

Hi, I have one question about SIP Service Calls range and it's range checking. Based on DEN0028E SIP Service Calls ranges are 0x82000000-0x8200FFFF SMC32: SiP Service Calls 0xC2000000-0xC200FFFF SMC64: SiP Service Calls That's the ranges which we are using for implementing SOC specific SMC handlers and I found that in past it was also added code which is out of this range. Specifically in Xilinx ZynqMP you can see code like this if (is_em_fid(smc_fid)) { return em_smc_handler(smc_fid, x1, x2, x3, x4, cookie, handle, flags); } where EM range is 0x820e0001- 0x820e0003 is out of our range which is assigned to us. But there is no failure at all that we are out of ranged in spec. Shouldn't this be enforced by core itself? That's why I just wanted to know your opinion about it. We will definitely implement better masking to find out that 0x00fe0000 are all zeros. But that bit 16 is based on DEN0028E related to smcccv1.3 which I think we are not supporting now that's why should be 0 too. But definitely some information about this bit should be useful. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs

2 years, 3 months

2
2
0 0

[LTS v2.8.0] Trusted Firmware-A LTS v2.8.0 Release Announcement

by Varun Wadekar

External email: Use caution opening links or attachments We are pleased to announce the release of the Trusted Firmware-A LTS version 2.8.0 [1]. To help with the verification and stability of the release, we also created side branches for Trusted Firmware-A Tests [2] and TF-A OpenCI Scripts/Jobs [3]. These went live on 13th February 2023. The trusted-firmware-a repository is now open again. On behalf of the TF-A LTS project maintainers, I would like to thank the Trustedfirmware.org TF-A Project community for the support and guidance. Notable features of the TF-A LTS Version 2.8.0 Release are as follows: TF-A Project Repository * Resolved issues * Workarounds for the following CPU errata * Cortex-A510 erratum 2684597 * Cortex-A710 erratum 2282622 * Cortex-A710 erratum 2768515 * Cortex-A78 erratum 2772019 * Cortex-A78 erratum 2779479 * Cortex-A78C erratum 2772121 * Cortex-X2 erratum 2282622 * Cortex-X2 erratum 2768515 * Cortex-X3 erratum 2615812 * Neoverse N2 erratum 2743089 * Neoverse V1 erratum 2743093 * Neoverse V1 errata 2779461 * Mitigations for the security advisory #10 * Critical bug fixes for the following platforms * Arm/CSS * Intel * Layerscape * LS1046a * LX2 * NXP * ST Patch Statistics * 35 Patches merged since v2.8 Nov 2022 release Please refer to the TF-A LTS [1] changelog for the complete summary of changes. [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/chang… [2] tf-a-tests.git - Trusted Firmware-A Tests<https://git.trustedfirmware.org/TF-A%2Ftf-a-tests.git/log/?h=refs%2Fheads%2…> [3] tf-a-ci-scripts.git - Trusted Firmware A (TF-A) CI scripts<https://git.trustedfirmware.org/ci%2Ftf-a-ci-scripts.git/log/?h=refs%2Fhead…> [4] tf-a-job-configs.git - Trusted Firmware A (TF-A) Jenkins job configs<https://git.trustedfirmware.org/ci%2Ftf-a-job-configs.git/log/?h=refs%2Fhea…>

2 years, 3 months

1
0
0 0

Coding guidelines update: Discouraging usage of weak functions

by Sandrine Bailleux

Hi all, As you may know, the TF-A project historically used to make heavy use of weak functions. The code base has numerous examples of them. However, based on previous discussions, I think we have general consensus in the TF-A community that the disadvantages of weak functions outweigh their benefits and for this reason we should discourage introducing new ones. In practice, I think this policy is already enforced most of the time in code reviews but I've now posted a patch that makes it explicit in the project's coding guidelines and provide the rationale behind it. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19398 Note that TF-A maintainers would still be responsible for enforcing this policy, as the CI system won't flag that for them, mainly because I think there might be legitimate cases for weak functions in rare instances so we'd get some false positives from such checks. We (at Arm) have got plans to gradually convert existing weak functions to strongly-defined implementations across the code base but this will take time. Like I said, I don't expect this change to be too controversial but please raise any concerns you may have in this email thread or on Gerrit. Best regards, Sandrine

2 years, 3 months

3
6
0 0

[PATCH 1/2] fix(cert-create): move WARN to higher priority than NOTICE

by Baruch Siach

NOTICE messages should require higher LOG_LEVEL than WARN, not the other way around. Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Iba9c67cafed19be47e7d03198faa98fbf99a10ee --- I still can't upload to review.trustedfirmware.org so I'm once again sending to the list instead. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- tools/cert_create/include/debug.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/cert_create/include/debug.h b/tools/cert_create/include/debug.h index ee8f1f51786f..8f7c62eefe2d 100644 --- a/tools/cert_create/include/debug.h +++ b/tools/cert_create/include/debug.h @@ -20,8 +20,8 @@ #define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 10 -#define LOG_LEVEL_NOTICE 20 -#define LOG_LEVEL_WARNING 30 +#define LOG_LEVEL_WARNING 20 +#define LOG_LEVEL_NOTICE 30 #define LOG_LEVEL_INFO 40 #define LOG_LEVEL_VERBOSE 50 -- 2.39.0

2 years, 3 months

2
2
0 0

[LTS v2.8.0] RC0 tag has been created

by Varun Wadekar

Hello, As announced in the last Tech forum, the code freeze date for the LTS branch was Feb 3, 2023. We have now merged all the patches published on the wiki [1]. The branch is still locked, and all the CI test runs have now been completed. We are trying to root cause one test failure, though. The RC0 tag was created today, and we request platform owners test the branch [2] on their downstream platforms if they wish. We are still on track to release on Feb 10 and will publish more updates shortly. Thanks. [1] ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>. [2] trusted-firmware-a.git - Trusted Firmware for A profile Arm CPUs<https://git.trustedfirmware.org/TF-A%2Ftrusted-firmware-a.git/log/?h=refs%2…>

2 years, 4 months

1
0
0 0

[LTS v2.8.0] The branch is now locked

by Varun Wadekar

External email: Use caution opening links or attachments Hello, As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have now locked the branch and won’t be accepting any more commits. The list of the commits that will be merged into the LTS branch can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>. If there are commits that we missed or that need to be in the LTS branch, please reach out to us. We will post more updates shortly. Thanks.

2 years, 4 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Feb 9, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Updating the agenda for the TF-A Tech Forum session on Feb 9th 2023." Changed: description TF-A Tech Forum Thursday Feb 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Title: Firmware update support in the Trusted Services projectPresented by: Julian HallA reference implementation of the Update Agent has recently been added to Trusted Services. The implementation provides a toolbox of reusable components for adding banked FWU support into firmware for A-Profile devices. The implementation conforms to the Arm FWU-A specification for compatibility with TF-A and other boot loaders that recognise FWU-A metadata.===================================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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org julian.hall(a)arm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

[LTS v2.8.0] TF-A patches are now ready for merge

by Varun Wadekar

Hello, As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have started shortlisting the patches for the lts-v2.8 branch. These are the commits that will be merged into the LTS branch. More details can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://developer.trustedfirmware.org/w/tf_a/tf-a_lts_meeting_minutes/track…> 1. c7e698cfd fix(cpus): workaround for Cortex-X3 erratum 2615812 2. c45791b2f fix(layerscape): fix errata a008850 3. fa0105693 fix(nxp-ddr): use CDDWW for write to read delay 4. 00bb8c37e fix(nxp-ddr): apply Max CDD values for warm boot 5. 07d8e34fd fix(nxp-drivers): fix tzc380 memory regions config 6. c0c157a68 fix(ls1046a): 4 keys secureboot failure resolved 7. 50aa0ea7a fix(lx2): init global data before using it 8. 4daeaf341 fix(sptool): add dependency to SP image 9. 5fb6946ad fix(console): fix crash on spin_unlock with cache disabled 10. ff1d2ef38 fix(el3_runtime): restore SPSR/ELR/SCR after esb 11. c42402cdf fix(intel): fix fcs_client crashed when increased param size 12. 0ca1d8fba fix(layerscape): unlock write access SMMU_CBn_ACTLR 13. b87b02cf1 fix(cpus): workaround for Cortex-A710 erratum 2768515 14. 1cfde8222 fix(cpus): workaround for Cortex-X2 erratum 2768515 15. 377846b65 fix(st): include utils.h to solve compilation error 16. 1cbe42a51 fix(el3_runtime): allow SErrors when executing in EL3 17. 1ee7c8232 fix(cpus): workaround for Neoverse N2 erratum 2743089 18. b10afcce5 fix(cpus): workaround for Cortex-A78 erratum 2772019 19. 31747f057 fix(cpus): workaround for Neoverse V1 erratum 2743093 20. fd37982a1 fix(auth): forbid junk after extensions 21. 72460f50e fix(auth): require at least one extension to be present 22. 06c01b085 fix(libc): properly define SCHAR_MIN 23. 89d85ad0a fix(cpus): workaround for Cortex-A710 erratum 2282622 24. abb8f936f fix(auth): avoid out-of-bounds read in auth_nvctr() 25. f5c51855d fix(auth): properly validate X.509 extensions 26. f9c6301d7 fix(cpus): workaround for Cortex-X2 erratum 2282622 27. 60719e4e0 fix(plat/css): fix invalid redistributor poweroff 28. 00230e37e fix(cpus): workaround for Cortex-A78C erratum 2772121 29. aea4ccf8d fix(cpus): workaround for Cortex-A510 erratum 2684597 If there are commits that we missed or that need to be in the LTS branch, please reach out to us. Thanks.

2 years, 4 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time Apologies the LTS Update is for this week on 26th January at 4pm GMT Not February session.=====Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun WadekarOkash Khawaja Bipin Ravi Thanks AllJoanna========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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org bpeckham(a)google.com mayurvg(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun Wadekar <vwadekar(a)nvidia.com> Okash Khawaja <okash(a)google.com> Bipin Ravi <Bipin.Ravi(a)arm.com>Thanks AllJoanna===============================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/Trusted 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 Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

[TF-A]: Deprecating mbedtls-2.28 support for TF-A 3.0 release

by Govindraj Raja

Hi All, We are in the process of migrating from mbedtls-2.28 support to 3.3 support we plan to deprecate mbedtls-2.28 support for TF-A 3.0 Release but would retain support for both 2.28 and 3.3 for TF-A 2.9 lifetime. There is draft implementation available[1] for code review which cleanups and prepares for mbedtls-3.3 support but retaining backward compatibility for mbedtls-2.28. Please let us know if there any objections to deprecation of mbedtls-2.28 in TF-A 3.0. -- Thanks Govindraj [1]: https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522 <https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522>

2 years, 4 months

1
0
0 0

Query BL31 version from NWd

by Varun Wadekar

Hi, Happy new year! For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value. I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement. Thoughts? -Varun

2 years, 4 months

8
18
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 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() ________________________________________________________________________________________________________ *** CID 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() 167 dest = (struct constraint_status *)st->value; 168 do { 169 if (dest == NULL) { 170 break; 171 } 172 if (st->type == CONSTRAINT_GET_VALID) { >>> CID 382954: Concurrent data access violations (MISSING_LOCK) >>> Accessing "dest->is_valid" without holding lock "spm_lock". Elsewhere, "constraint_status.is_valid" is accessed with "spm_lock" held 5 out of 6 times. 173 dest->is_valid = cpubuckldo_status; 174 } else if (st->type == CONSTRAINT_COND_BLOCK) { 175 dest->is_cond_block = 0; 176 } else if (st->type == CONSTRAINT_GET_ENTER_CNT) { 177 if (st->id == MT_RM_CONSTRAINT_ID_ALL) { 178 dest->enter_cnt += cpubuckldo_enter_cnt; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 4 months

1
0
0 0

Post-boot loading of OP-TEE

by Jens Wiklander

Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [3] https://github.com/OP-TEE/optee_os/issues/5699 Thanks, Jens

2 years, 4 months

3
3
0 0

New vulnerability: Out-of-bounds read in TF-A X.509 parser

by Sandrine Bailleux

Hello everyone, A new security vulnerability has been identified in TF-A X.509 parser, used for trusted boot in BL1 and BL2. Please note that this vulnerability is *not* exploitable in TF-A upstream code. Only downstream code might be affected under specific circumstances. The security advisory has been published in TF-A documentation and has all the details: https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu… Patches to fix the identified bugs have already been merged in TF-A tree. The advisory lists the relevant patches. I would like to thank Demi Marie Obenour from Invisible Things Lab for responsibly disclosing this security vulnerability to TrustedFirmware.org, for providing patches to fix the identified bugs and further harden the X.509 parser, for providing a detailed impact analysis and for helping put this security advisory together. Best regards, Sandrine Bailleux, on behalf of TF-A security team.

2 years, 4 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Correcting the deletion of the wrong Techforum." Changed: time TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time 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   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topic this week. Cancelling. Joanna" TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time 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   Guests 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 email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

TF-A Tech Forum Sessions Jan/Feb

by Joanna Farley

Hi all, With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me. If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held. Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates: * 12th January – No topic * 26th January – LTS Update * 9th February – No topic * 23rd February - Tech talk for PSCI OS-initiated mode Thanks Joanna

2 years, 4 months

1
2
0 0

Runtime loading of SEL-1

by Jeffrey Kardatzke

Hello, I'm working on a project for ChromeOS where we would like to be able to load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time. The reasoning behind this is that it's much easier to update the rootfs than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots. The main questions I have are if there are any issues people would be aware of by loading it after linux boots rather than during the usual BL32 stage? And I would definitely want to upstream this work if it's something we can do. Thanks, Jeffrey Kardatzke Google, Inc.

2 years, 5 months

7
14
1 0

Question about using rme for smmuv3

by Chenxu Wang

Hi all, I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is the branch "arm_cca_v0.3". When I boot my FVP, I set the following commands: -C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \ -C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \ -C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \ -C cluster0.rme_support_level=2 \ -C cluster1.rme_support_level=2 \ Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the SMMU Root Control Page should be 0x2b42_0000. Thus, I add the mapping to this region in plat_arm_mmap[], as: MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT) Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on the manual, its offset is 0x0, so I read 0x2b42_0000. However, it returns 0x0, which is not what I configured in the boot commands (I think it should be 0x3). Can someone tell me the reason for this? Sincerely, WANG Chenxu

2 years, 5 months

2
3
0 0

TF-A Tech-Forum Agenda for Thursday 15-Dec-22 at 4pm BST

by Bipin Ravi

Topic: QEMU Support in TF-A OpenCI Presented by: Harrison Mutai Agenda: Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to: * Do a quick demo on how to navigate the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests results. * Do a quick demo on how to run these tests on your local machine through TF-A CI scripts. * Give a high-level overview of the changes in TF-A CI scripts and OpenCI infrastructure that made this possible. [1] Supporting QEMU in OpenCI - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…> ================================================= 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/<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…> Thanks & best regards, --Bipin Ravi

2 years, 5 months

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 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() ________________________________________________________________________________________________________ *** CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() 72 uint32_t is_secure; 73 74 ipi_local_id = x1 & UNSIGNED32_MASK; 75 ipi_remote_id = x2 & UNSIGNED32_MASK; 76 77 if ((GET_SMC_OEN(smc_fid) >= OEN_TAP_START) && >>> CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "((smc_fid >> 24U) & 0x3fU) <= 63U" is always true regardless of the values of its operands. This occurs as the logical second operand of "&&". 78 (GET_SMC_OEN(smc_fid) <= OEN_TOS_END)) { 79 is_secure = 1; 80 } else { 81 is_secure = 0; 82 } 83 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 5 months

1
0
0 0

Upcoming "Stricter ASN.1 certificate parsing" patches

by Sandrine Bailleux

Hello everyone, I'd like to draw your attention on the following patch stack (contribution from Demi Marie Obenour, thank you!): https://review.trustedfirmware.org/q/owner:demiobenour%2540gmail.com+is:open These patches refactor the X.509 certificate parser leveraged by the trusted boot implementation in TF-A, such that the parser more closely follows the X.509 format specification [1] and ASN.1/DER encoding rules [2]. In a nutshell, this means that the X.509 parser is now stricter. Some ill-formatted certificates which TF-A would have previously accepted are now rejected. All trusted boot tests in the TF-A OpenCI have passed with these patches but I realize that this does not cover all platforms and use cases. Thus, I'd like to allow time for all platform maintainers that wish it to conduct their own testing and report any issue they're seeing on the mailing list. If we don't hear anything by end of Wednesday (14/12), we'll merge the patches. Best regards, Sandrine [1] See RFC5280, https://datatracker.ietf.org/doc/html/rfc5280 [2] ITU-T X.690, https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf

2 years, 6 months

1
0
0 0

[PATCH 1/1] plat/qemu: Improve aarch32 build support

by Rebecca Cran

While aarch32 isn't currently supported on qemu, platform.mk for both qemu and qemu_sbsa contain bugs that cause the build to fail earlier than it otherwise should. Correct usage of ${ARCH} and hardcoded aarch64 strings so that the correct files are built when ARCH=aarch32 is specified. Signed-off-by: Rebecca Cran <rebecca(a)quicinc.com> --- plat/qemu/qemu/platform.mk | 12 ++++++------ plat/qemu/qemu_sbsa/platform.mk | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/plat/qemu/qemu/platform.mk b/plat/qemu/qemu/platform.mk index dfc5de2ce43a..7b69ff76f3d6 100644 --- a/plat/qemu/qemu/platform.mk +++ b/plat/qemu/qemu/platform.mk @@ -45,7 +45,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -Iinclude/common/tbbr ifeq (${ARM_ARCH_MAJOR},8) -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 endif PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ @@ -138,11 +138,11 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_bl1_setup.c ifeq (${ARM_ARCH_MAJOR},8) -BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ - lib/cpus/aarch64/cortex_a53.S \ - lib/cpus/aarch64/cortex_a57.S \ - lib/cpus/aarch64/cortex_a72.S \ - lib/cpus/aarch64/qemu_max.S \ +BL1_SOURCES += lib/cpus/${ARCH}/aem_generic.S \ + lib/cpus/${ARCH}/cortex_a53.S \ + lib/cpus/${ARCH}/cortex_a57.S \ + lib/cpus/${ARCH}/cortex_a72.S \ + lib/cpus/${ARCH}/qemu_max.S \ else BL1_SOURCES += lib/cpus/${ARCH}/cortex_a15.S diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk index 5a6b1e11e812..05a66f81314f 100644 --- a/plat/qemu/qemu_sbsa/platform.mk +++ b/plat/qemu/qemu_sbsa/platform.mk @@ -30,7 +30,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -I${PLAT_QEMU_PATH}/include \ -Iinclude/common/tbbr -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_console.c \ -- 2.30.2

2 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A