- TF-A - lists.trustedfirmware.org

TF-A Tech-Forum Agenda for Thursday 21-Apr-22 at 4pm BST

by Joanna Farley

Topic: Feature Detection Mechanism Presented by : Jayanth Chidanand Agenda: Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions. I will be covering the implementation work completed so far and the impact of References: TF-A Mailing List Post<https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…> Patches<https://review.trustedfirmware.org/q/topic:%22jc%252Fdetect_feat%22+(status…> Documentation<https://trustedfirmware-a.readthedocs.io/en/latest/search.html?q=FEATURE_DE…> ================================================= 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://www.trustedfirmware.org/meetings/tf-a-…> 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 6 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================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   (changed) When: Thu Apr 21, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 6 months

1
0
0 0

Status of MTE for bl31

by Okash Khawaja

Hi, I wanted to check the status of MTE support for bl31 itself. It seems like the support was added [1] for clang and armclang but I couldn't find the memory attribute to map pages as tag checked [2]. Is there something I missed? Thanks, Okash [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… [2] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

3 years, 6 months

3
7
0 0

MTE support at S-EL1

by Jens Wiklander

Hi, I've started to experiment with MTE in OP-TEE at S-EL1. I've compiled TF-A with CTX_INCLUDE_MTE_REGS and I'm testing this on QEMU. Before trying to use MTE in OP-TEE I check id_aa64pfr1_el1 and skip MTE initializations if unavailable. This works as long as TF-A always is compiled with CTX_INCLUDE_MTE_REGS if MTE is available. If TF-A is compiled without CTX_INCLUDE_MTE_REGS OP-TEE will be trapped into EL3 when trying to access one of the MTE registers. I suppose this is because SCR_EL3.ATA is 0. Is there a way for OP-TEE to tell if the MTE registers are safe to access? Thanks, Jens

3 years, 6 months

2
2
0 0

TF-a would not handle PSCI_CPU_ON_AARCH64 if forwarded by a hypervisor

by Mushahid Hussain

Hi, I'm working on a hobby project: AARCH64 Hypervisor on Raspberry Pi 4b. I have a problem with trapping a psci smc. I'll explain everything and what steps I have followed. Right now, I'm implementing SMC trapping. I can successfully forward almost all SMCs except for PSCI_CPU_ON_AARCH64. Linux makes these SMCs to bring up secondary CPUs during booting. Here's what I'm trying to do: - trap the PSCI_CPU_ON_AARCH64 SMC, - preserve the entry_point address in global variable - replace the entrypoint with my entrypoint and make the smc to tf-a(or simply forward it.) - when secondary cpus come online at the given address, where I set their stack point and then eret the original address. Secondary cpus won't come online at the given address. Even if I don't change any arguments of CPU_ON smc and forward it as it is, the secondary cpus still won't come online. However, without trapping enabled(HCR_EL2.TSC=0), everything works fine. I tried to debug inside Trusted Firmware. I know that overall path for secondary CPU hotplug in is: CPU released from reset -> (ROM and possibly some other bootloader) -> bl31/aarch64/bl31_entrypoint.S:bl31_warm_entrypoint() -> lib/psci/psci_common.c:psci_warmboot_entrypoint() -> lib/psci/psci_on.c:psci_cpu_on_finish() -> rpi3_pwr_domain_on_finish() I printed at all these points in Trusted Firmware with and without trapping enabled. Here's what I found: Nothing gets printed anywhere in that path if trapping is enabled. However, without trapping enabled, I can print anywhere even in bl31_entrypoint.S:bl31_warm_entrypoint(). What could be the problem? Here's my code: https://github.com/SikkiLadho/Leo/blob/4f272eff39934058a7f989c91aad82eab810… -- Mushahid Hussain

3 years, 6 months

1
0
0 0

Cortex-X1 support

by Okash Khawaja

Hello, Are there any immediate plans to add support for Cortex-X1 in TF-A? If not then I'll be happy to submit CL for it. For start, it will cover a subset of errata workarounds. Then people can add more as needed. Let me know what you think. Thanks, Okash

3 years, 6 months

2
2
0 0

TF-A Tech Forum Agenda this week

by Joanna Farley

Session this week will be: * CCA Attestation and Measured boot * Presented by Tamas Ban * As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974

3 years, 6 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Apr 7, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed with this note: "Agenda for this week: Session this week will be: CCA Attestation and Measured boot Presented by Tamas Ban As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…" Title: TF-A Tech Forum Session this week will be:CCA Attestation and Measured bootPresented by Tamas BanAs a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… 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   (changed) When: Thu Apr 7, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 6 months

1
0
0 0

[Feedback required] Feature detection mechanism

by Manish Pandey2

Hello All, We are sending this note, to notify you of all the implementation details related to the Architectural Features Detection Mechanism. Summary: This is a diagnostic tool, which is targeted to mitigate the runtime exceptions due to incorrect feature enablement. This is currently marked as experimental and disabled by default, but our target is to make it mandatory over the time. All the platform owners are expected to read the details(and review the patch) and give it a try by enabling this mechanism and share your thoughts/feedback or any questions to @Jayanth Dodderi Chidanand<mailto:JAYANTHDODDERI.CHIDANAND@arm.com> or me. Patches under Review: https://review.trustedfirmware.org/q/topic:jc/detect_feat Details: 1. What is Feature Detection Mechanism? * Feature Detection is a procedure/mechanism aimed at identifying the features which are enabled ( by software) and not detected/supported in the hardware. * It could be considered as a diagnostic tool to quickly check and get assured which features are not supported by the hardware at an early stage of booting. 2. Why do we need it? Currently, most of the feature-specific register's context management, save and restore routines are conditionally controlled with the ARM_ARCH_AT_LEAST macro, which is primarily causing exceptions under various scenarios like: * For a given version of the architecture, the optional and mandatory features control the access to various registers. If the given version of implementation does not support both, unconditional access to such registers leads to undefined behaviour. * Accessing registers without verifying their actual presence for the given implementation. In general, the problem is broader than just this specific case. We should not rely on ARM_ARCH_AT_LEAST macro to associate with an architecture extension but rather supply the individual ENABLE_FEAT_xxx option for each feature. Again, having individual build flags, won't resolve this completely. There is still room for error as users may unknowingly enable the flags. So, the build flags still need to be validated before performing any action guarded by them. This mechanism helps in resolving this issue completely. It assists in detecting the features which are not present in the platform but are enabled by software unknowingly. It prevents the runtime exception, due to the consequences already mentioned. 3. How have we designed and implemented it? We are introducing a tri-state approach for each feature build flag. From now on, the build flags take three values/states ( 0,1 or 2), and they imply as follows: The 3 states are: * ENABLE_FEAT_xxx = 0: The feature is disabled statically at compile time. * ENABLE_FEAT_xxx = 1: The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. * ENABLE_FEAT_xxx = 2: The feature is enabled and detected at runtime Based on the value defined for each feature flag, they get detected either at boot-time or at runtime, respectively. For simplicity, let's take FEAT_HCX which is available in arch version 8.7. We provide a build option for enabling this feature, say "ENABLE_FEAT_HCX". * ENABLE_FEAT_HCX=0; The feature is disabled statically at compile time. * ENABLE_FEAT_HCX=1; The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. i.e., we detect, whether the HCX feature is present in the PE, by reading its ID register and if not, panic will be called. Thereby at an early boot phase, we stop and report that FEAT_HCX is not supported by PE. * ENABLE_FEAT_HCX=2; The feature is enabled but dynamically enabled at runtime depending on hardware capability. Here, a feature detection check will happen during runtime. 4. What is the status of this implementation? Is it completely implemented and tested? We have divided the entire implementation into two phases. In phase-1 FEAT_STATES { 0, 1} are handled and FEAT_STATE{2} will be handled ahead. Currently, we are in phase-1 delivery, wherein we are introducing a procedure, which will read through all the enabled feature build flags, and if they are defined to state1, ENABLE_FEAT_XXX=1 the respective feature will be detected. 5. Which all features are considered here? TF-A supports most arm architectural features from v8.0 and upwards. Some are mandatory and some are optional features as per the Arm ARM docs. So, both ( Mandatory and optional features from v8.0) are detected under this mechanism. 6. Does this mechanism modify or impact any existing implementation related to any of the architectural features supported in TF-A? * Yes. * Ideally, TF-A enables the architectural features which are mandatory by default from a particular arch version and upwards ( as per Arm-ARM docs ) and disables the optional features by default and allows the platforms to make the decision on enabling the optional feature based on their requirements. * This pattern is followed for most of the features. However, there are some cases wherein optional features are enabled by default within TF-A ( Eg; FEAT_SPE, FEAT_SVE ), which shouldn't have been handled this way. * With the feature detection mechanism in place, as stated earlier the procedure runs through all the enabled features(optional and mandatory) and identifies them. * Now, FEAT_SPE and FEAT_SVE are optional features, which are enabled by default and when detected will not be identified by the PE, if it doesn't support it and panics during booting. * So, since we have enabled these optional features within the TF-A build system, it would panic and stop booting. * If we upstream this mechanism, all the partner's platforms will be impacted involuntarily. This problem will not be seen in other cases like: * Mandatory Feature: Let's say FEAT_FGT which is mandatory from the 8.6 version. So, if a platform is based on v8.6 it will implement this, and this feature will be detected. So no issue here. If the platform is based on v8.5, this FEAT_FGT is not enabled by the TF-A. It gets enabled from 8.6. So here, in this case, the feature is disabled so nothing to worry about. * Optional Feature: Let's say FEAT_NV2 which is an optional feature from arch version 8.4. is supported by TF-A. Since it is an optional one as per Arm ARM, TF-A implements and disables it by default and allows the platforms to decide and enable them as per their requirements. So here, if the platform enables it, it implies they are sure this feature is implemented. If not, this mechanism will help them by detecting it, so that they disable it in future. In general, this would not break the boot flow in all scenarios. But if the optional feature is enabled by TF-A itself, will stop the boot flow in most of scenarios. So, to avoid breaking change, we have decided to overlook such optional features for now and update our partners and get their feedback. Based on that, in future, we will disable these optional features which were enabled by default and will send another email to enable it explicitly according to their requirements. 7. What should the platforms be aware of, with the upstreaming of this mechanism? * Currently, we are introducing this entire implementation as an experimental mechanism, wherein we provide an explicit build flag (FEATURE_DETECTION) to enable the feature detection mechanism itself. We urge the platforms to enable this mechanism, test it and get used to its behaviour before it gets mandated. * So, for now, it wouldn't cause any issue. But our plan is to make sure this mechanism runs by default, as we want to mitigate the runtime Exceptions. As part of the 2.7 release, we are targeting to upstream this implementation and later, have some time window, wherein our partners get used to it and provide feedback as well. 8. Will there be any breakdown during runtime, with respect to any of the platforms? Yes. It's explained in detail above. 9. What is the long-term plan with this mechanism? When will this be completely implemented and tested end to end? We target it to be implemented full-fledged by EoY 2022, but it depends on the feedback received from our partners and get this done. Thanks

3 years, 6 months

1
0
0 0

ENABLE_PIE with clang

by Okash Khawaja

Hi, It seems like setting ENABLE_PIE=1 and compiling with clang/LLVM results in linker errors. E.g. compiling ti/k3 which has ENABLE_PIE=1, with clang and lld version 14.0.1 results in linker errors like "ld.lld: error: can't create dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output". Is this expected? If not, are there any plans to fix this? Thanks, Okash

3 years, 7 months

2
2
0 0

CCA Attestation and Measured boot

by Tamas Ban

Hi, In Arm CCA the Security Model strongly recommends implementing the CCA HES functionality to ensure the system security properties. A way to achieve this is to add a trusted subsystem to the system, which behaves like a secure enclave. In ARM reference design this trusted subsystem is called to Runtime Security Subsystem (RSS). RSS can execute a firmware component that implements the functional requirements of the HES. But its firmware is not restricted to be only the HES, other tenants are also allowed. The goal of the CCA HES is to provide fundamental services to the AP to ensure its security properties. These fundamental services include secure boot, measured boot and attestation, etc. You can find more information about the role of CCA HES and about its functional requirements in the Arm CCA Security Model [1]. In ARM reference design the CCA HES is going to be executed by RSS. CCA HES is based on TF-M. In this patch series [2] the AP side support of the CCA HES functionalities is going to be introduced: - Communication over an MHU channel between the AP and RSS. - Communication abstracted by the PSA API. So, AP can leverage standard PSA calls to invoke these services on the RSS. - CCA HES provides a measured boot backend. Measurements are taken during AP boot can be stored by RSS and retrieved as part of the CCA Platform Attestation token. - CCA Platform Attestation token can be requested from RSS. Currently, there is no publicly available FVP platform to test these patches, but it will be available later this year. Some limited testing is available on the AEM FVP. Here the RSS based measured boot backend is enabled and mocked version of the measured boot and attestation APIs are available. Due to the lack of RSS in the FVP, the APIs do not communicate to RSS, instead just print the measurements to the console and return to a hard-coded attestation token. [1] https://developer.arm.com/documentation/DEN0096/latest [2] https://review.trustedfirmware.org/q/topic:%2522rss/mboot-attest%2522 Best regards, Tamas Ban

3 years, 7 months

1
0
0 0

Mbed TLS GitHub migration

by dave.rodgman＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years, 7 months

1
0
1 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 376885: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 376885: Integer handling issues (NEGATIVE_RETURNS) /drivers/st/clk/clk-stm32-core.c: 343 in _clk_stm32_set_parent() 337 if (parents->id_parents[sel] == (uint16_t)clkp) { 338 bool clk_was_enabled = _clk_stm32_is_enabled(priv, clk); 339 int err = 0; 340 341 /* Enable the parents (for glitch free mux) */ 342 _clk_stm32_enable(priv, clkp); >>> CID 376885: Integer handling issues (NEGATIVE_RETURNS) >>> "old_parent" is passed to a parameter that cannot be negative. 343 _clk_stm32_enable(priv, old_parent); 344 345 err = clk_mux_set_parent(priv, pid, sel); 346 347 _clk_stm32_disable(priv, old_parent); 348 ** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() ________________________________________________________________________________________________________ *** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() 2213 ERROR("Unsupported DIMM type\n"); 2214 return -EINVAL; 2215 } 2216 2217 size = PHY_GEN2_MAX_IMAGE_SIZE; 2218 image_buf = (uintptr_t)phy_gen2_fw_img_buf; >>> CID 376884: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 14 out of 16 times). 2219 mmap_add_dynamic_region(phy_gen2_fw_img_buf, 2220 phy_gen2_fw_img_buf, 2221 PHY_GEN2_MAX_IMAGE_SIZE, 2222 MT_MEMORY | MT_RW | MT_SECURE); 2223 ret = img_loadr(imem_id, &image_buf, &size); 2224 if (ret != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 7 months

1
0
1 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 9am - 10am (MST) (tf-a@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled. 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 Mar 24, 2022 9am – 10am Mountain Standard Time - Phoenix 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 * don.harbin(a)linaro.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

3 years, 7 months

1
0
0 0

TF-A Tech Forum

by Joanna Farley

Not sure if the cancellation has gone out but just confirming this Tech Forum is cancelled. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 24 March 2022 Subject: TF-A Tech Forum You have been invited to the following event. TF-A Tech Forum When Thu Mar 24, 2022 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 more details »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> more options »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> 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<https://support.google.com/calendar/answer/37135#forwarding>.

3 years, 7 months

1
0
0 0

TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) CANCELLED

by Joanna Farley

Just confirming that the TF-A Tech forum this week is cancelled due to no subject/topic. Thanks Joanna

3 years, 7 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

You have been invited to the following event. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Mar 24, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 7 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. 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 Mar 24, 2022 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

3 years, 7 months

1
0
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 7 months

1
0
0 0

TF-A Technical Forum Session Agenda for Today

by Joanna Farley

I understand some people may not have seen the calendar invite for today’s Tech Forum session. It is in the archives but formatting has been lost so just confirming the agenda in plain email to the list. Joanna Agenda for Session on 10th March 2022 * Introduction to Arm DRTM specification and its support in TF-A * Stuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest%C2%A0Manish * Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details: * Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time. * Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations. 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://www.trustedfirmware.org/meetings/tf-a-…> 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 7 months

1
1
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. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() 270 SMC_RET1(handle, SMC_UNK); 271 272 pm_arg[0] = (uint32_t)x1; 273 pm_arg[1] = (uint32_t)(x1 >> 32); 274 pm_arg[2] = (uint32_t)x2; 275 pm_arg[3] = (uint32_t)(x2 >> 32); >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 276 pm_arg[4] = (uint32_t)x3; 277 278 api_id = smc_fid & FUNCID_NUM_MASK; 279 280 switch (api_id) { 281 /* PM API Functions */ /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() 547 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)version << 32), 548 (uint64_t)bit_mask[0] | ((uint64_t)bit_mask[1] << 32)); 549 } 550 551 default: 552 /* Send request to the PMU */ >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 553 PM_PACK_PAYLOAD6(payload, api_id, pm_arg[0], pm_arg[1], 554 pm_arg[2], pm_arg[3], pm_arg[4]); 555 ret = pm_ipi_send_sync(primary_proc, payload, result, 556 PAYLOAD_ARG_CNT); 557 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)result[0] << 32), 558 (uint64_t)result[1] | ((uint64_t)result[2] << 32)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 7 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for TF-A Tech Forum on 10th March 2022Introduction to Arm DRTM specification and its support in TF-AStuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest M… Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details:Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time.Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations.=========================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   (changed) When: Thu Mar 10, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 7 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. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 12 of 12 defect(s) ** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() 201 if (pwrlvl == PSCI_INVALID_PWR_LVL) { 202 ERROR("Invalid target power level for PSCI statistics operation\n"); 203 panic(); 204 } 205 206 /* Get the index into the stats array */ >>> CID 376586: Memory - illegal accesses (OVERRUN) >>> Overrunning array "state_info.pwr_domain_state" of 2 bytes at byte offset 3 using index "pwrlvl" (which evaluates to 3). 207 local_state = state_info.pwr_domain_state[pwrlvl]; 208 stat_idx = get_stat_idx(local_state, pwrlvl); 209 210 if (pwrlvl > PSCI_CPU_PWR_LVL) { 211 /* Get the power domain index */ 212 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); ** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() ________________________________________________________________________________________________________ *** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() 489 * Save the counters to the local context. 490 */ 491 492 isb(); /* Ensure counters have been stopped */ 493 494 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 495 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 496 } 497 498 #if ENABLE_AMU_AUXILIARY_COUNTERS 499 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 500 ctx->group1_cnts[i] = amu_group1_cnt_read(i); /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() 331 * Save the counters to the local context. 332 */ 333 334 isb(); /* Ensure counters have been stopped */ 335 336 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 337 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 338 } 339 340 #if ENABLE_AMU_AUXILIARY_COUNTERS 341 for (i = 0U; i < amcgcr_cg1nc; i++) { 342 ctx->group1_cnts[i] = amu_group1_cnt_read(i); ** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() 579 580 /* 581 * Restore the counter values from the local context. 582 */ 583 584 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 585 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 586 } 587 588 #if ENABLE_AMU_AUXILIARY_COUNTERS 589 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 590 amu_group1_cnt_write(i, ctx->group1_cnts[i]); /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() 390 391 /* 392 * Restore the counter values from the local context. 393 */ 394 395 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 396 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 397 } 398 399 #if ENABLE_AMU_AUXILIARY_COUNTERS 400 for (i = 0U; i < amcgcr_cg1nc; i++) { 401 amu_group1_cnt_write(i, ctx->group1_cnts[i]); ** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); 304 pdram_timing->twtr = max(4, tmp); 305 pdram_timing->trtw = DDR3_TRTW; 306 pdram_timing->tras_max = 9 * pdram_timing->trefi; 307 pdram_timing->tras_min = ((DDR3_TRAS * nmhz + (nmhz >> 1) + 999) 308 / 1000); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 309 pdram_timing->tfaw = 310 (((ddr3_trc_tfaw[ddr_speed_bin] & 0x0ff) * nmhz + 999) 311 / 1000); 312 /* tRFC, 90ns(512Mb),110ns(1Gb),160ns(2Gb),300ns(4Gb),350ns(8Gb) */ 313 if (ddr_capability_per_die <= 0x4000000) 314 tmp = DDR3_TRFC_512MBIT; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() 292 else 293 pdram_timing->mr[0] = DDR3_BL8 294 | DDR3_CL(pdram_timing->cl) 295 | DDR3_WR(tmp); 296 tmp = ((DDR3_TRTP * nmhz + (nmhz >> 1) + 999) / 1000); 297 pdram_timing->trtp = max(4, tmp); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 298 pdram_timing->trc = 299 (((ddr3_trc_tfaw[ddr_speed_bin] >> 8) * nmhz + 999) / 1000); 300 tmp = ((DDR3_TRRD * nmhz + 999) / 1000); 301 pdram_timing->trrd = max(4, tmp); 302 pdram_timing->tccd = DDR3_TCCD; 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); ** CID 376582: (UNINIT) ________________________________________________________________________________________________________ *** CID 376582: (UNINIT) /drivers/st/clk/stm32mp1_clk.c: 1928 in stm32mp1_clk_init() 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL4]" when calling "stm32mp1_check_pll_conf". 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], 1930 pllcfg[_PLL4], 1931 plloff[_PLL4]); 1932 } 1933 /* Don't initialize PLL4, when used by BOOTROM */ /drivers/st/clk/stm32mp1_clk.c: 1924 in stm32mp1_clk_init() 1918 if (ret != 0) { 1919 return ret; 1920 } 1921 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL3]" when calling "stm32mp1_check_pll_conf". 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], ** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() ________________________________________________________________________________________________________ *** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() 383 boot_source = boot_source_get(); 384 if (image_id == FIP_IMAGE_ID) 385 policy = &boot_source_policies[boot_source]; 386 else 387 policy = &policies[image_id]; 388 >>> CID 376581: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 168 by dereferencing pointer "policy". 389 result = policy->check(policy->image_spec); 390 if (result == 0) { 391 *image_spec = policy->image_spec; 392 *dev_handle = *(policy->dev_handle); 393 394 if (image_id == TRUSTED_BOOT_FW_CERT_ID) { ** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() ________________________________________________________________________________________________________ *** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() 239 int i = 0, ret = 0; 240 uint32_t *desc_addr = jobdesc->desc; 241 uint32_t desc_len = desc_length(jobdesc->desc); 242 uint32_t desc_word; 243 244 for (i = 0; i < desc_len; i++) { >>> CID 376580: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 64 4-byte elements at element index 126 (byte offset 507) by dereferencing pointer "desc_addr + i". 245 desc_word = desc_addr[i]; 246 VERBOSE("%x\n", desc_word); 247 sec_out32((uint32_t *)&desc_addr[i], desc_word); 248 } 249 dsb(); 250 ** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() ________________________________________________________________________________________________________ *** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() 214 node = irq_to_pm_node(irq); 215 reg &= ~lowest_set; 216 217 if ((node != NODE_UNKNOWN) && 218 (!pm_wakeup_nodes_set[node])) { 219 ret = pm_set_wakeup_source(NODE_APU, node, 1); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 78 bytes at byte offset 127 using index "node" (which evaluates to 127). 220 pm_wakeup_nodes_set[node] = !ret; 221 } 222 } 223 } 224 } 225 /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() 143 break; 144 } 145 146 node_idx = irq_to_pm_node_idx(irq); 147 reg &= ~lowest_set; 148 >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 149 if ((node_idx != XPM_NODEIDX_DEV_MIN) && 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, 155 SECURE_FLAG); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 156 pm_wakeup_nodes_set[node_idx] = (uint8_t)(!ret); 157 } 158 } 159 } 160 } 161 ** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() 527 528 case PM_CLOCK_GETRATE: 529 { 530 uint64_t value; 531 532 ret = pm_clock_getrate(pm_arg[0], &value); >>> CID 376578: Uninitialized variables (UNINIT) >>> Using uninitialized value "value". 533 SMC_RET2(handle, (uint64_t)ret | 534 (((uint64_t)value & 0xFFFFFFFFU) << 32U), 535 (value >> 32U) & 0xFFFFFFFFU); 536 537 } 538 ** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: 241 tmp = DDR3_DS_40; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() 229 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: ** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() ________________________________________________________________________________________________________ *** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() 42 ret = dfd_smc_dispatcher(x1, x2, x3, x4); 43 SMC_RET1(handle, ret); 44 break; 45 case MTK_SIP_APUSYS_CONTROL_AARCH32: 46 case MTK_SIP_APUSYS_CONTROL_AARCH64: 47 ret = apusys_kernel_ctrl(x1, x2, x3, x4, &ret_val); >>> CID 376576: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret_val". 48 SMC_RET2(handle, ret, ret_val); 49 break; 50 default: 51 ERROR("%s: unhandled SMC (0x%x)\n", __func__, smc_fid); 52 break; 53 } 54 55 SMC_RET1(handle, SMC_UNK); ** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() ________________________________________________________________________________________________________ *** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() 257 state->hold = 0; 258 state->bits = 0; 259 return Z_OK; 260 } 261 if (bits > 16 || state->bits + (uInt)bits > 32) return Z_STREAM_ERROR; 262 value &= (1L << bits) - 1; >>> CID 375635: Integer handling issues (BAD_SHIFT) >>> In expression "(unsigned int)value << state->bits", left shifting by more than 31 bits has undefined behavior. The shift amount, "state->bits", is as much as 32. 263 state->hold += (unsigned)value << state->bits; 264 state->bits += (uInt)bits; 265 return Z_OK; 266 } 267 268 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

[MPAM] Removing initialization of MPAM EL2 registers when EL2 is used

by Zelalem Aweke

Hi all, The small patch below [1] removes initialization of MPAM EL2 registers when EL2 is used, with the assumption that if an EL2 software exists it should perform the necessary initializations. Please take a look at the patch and let me know if this change affects any downstream projects. Thanks! Zelalem [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13805/7

3 years, 8 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 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() ________________________________________________________________________________________________________ *** CID 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() 136 137 while (*count < 3) { 138 139 status = mailbox_read_response(job_id, 140 resp, &resp_len); 141 >>> CID 376573: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "resp_len < 0U". 142 if (resp_len < 0) 143 break; 144 145 max_blocks++; 146 147 if (mark_last_buffer_xfer_completed( ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No topic to be presented this week. Cancelling meeting." 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 Feb 24, 2022 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

3 years, 8 months

1
0
0 0

Re: please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. This threads originates in a trivial fix for the 'clean' Makefile target. All contributions, even cosmetic and/or from the outside world, must follow the same formal process. Apparently, the process fails for external contributors. The discussion is visible there: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… At this moment, there were more people involved in the discussion than letters affected by the patch, so I was invited to switch to a private mail exchange. I was asked to describe the error messages, did so, and was forgotten ever since. Almost a year has passed, the patch is neither refused nor applied. The connection error still prevents some/all external contributions. The only effect of my request so far is that I have been obliged to create accounts on github and your gerrit instance. Is there hope for a more satisfying conclusion?

3 years, 8 months

2
1
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No topics prepared for this week." 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 Feb 10, 2022 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

3 years, 8 months

1
0
0 0

Is there any development roadmap(plan) for the Arm CCA features?

by Sangwan Kwon

Hi, I checked that TF-A supports FEAT_RME since v2.6. (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html) And those are developed on rme_prototype branch. ( https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=topics/r… ) But it is not updated since last year (September, 2021). I was wondering if there is a development plan or active branch about Arm CCA features (like RME RMM). BRs, Sangwan Kwon

3 years, 8 months

2
1
0 0

Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by Beom Heyn Kim

Hi, With RME enabled FVP_Base_RevC_2xAEMvA, we are trying to have TF-A's BL31 successfully exit EL3 and jump to a normal world boot firmware (edk2 UEFI boot loader) instead of tftf.bin. Yet, it fails with the following log messages (showing the last 3): INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 We could boot and run RMM and tftf.bin successfully following the instructions on the TF-A documentation page ( https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…). While keeping build and run commands same, we tried to just replace the tftf.bin with FVP_AARCH64_EFI.fd, the build artifact of the edk2-platform for ARM ( https://github.com/tianocore/edk2-platforms/tree/master/Platform/ARM) We checked both tftf.bin and FVP_AARCH64_EFI.fd cases result in the same entry point address 0x88000000. Yet, the latter stops after exiting EL3 as aforementioned, unlike tftf.bin which successfully proceeds to run some tests afterwards. Also, we found that FVP_AARCH64_EFI.fd can boot successfully with the same fast model but without RME enabled. What is the possible reason for this symptom and the necessary tweaks we should do to address this issue? What should we look for to get some clue? Cheers,

3 years, 8 months

2
1
0 0

Re: How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Manish Pandey2

Hi Yusuf, I hope you have gone through https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… 1. Distinguishing between a cold boot and a warm boot. 2. In the case of a cold boot and the CPU being a secondary CPU, ensuring that the CPU is placed in a platform-specific state until the primary CPU performs the necessary steps to remove it from this state. 3. In the case of a warm boot, ensuring that the CPU jumps to a platform- specific address in the BL31 image in the same processor mode as it was when released from reset. Secondary cores are kept in TF-A holding pen until primary core makes a request to start secondary core(from OS through PSCI CPU_ON). On receiving this call primary breaks the condition which held secondary. For example, investigate a5ds platform's plat_secondary_cold_boot_setup() & a5ds_pwr_domain_on(). Platform also provides warm_boot_entrypoint (most platform uses bl31_warm_entrypoint) from where secondary starts execution. Primary core is responsible for platform initialization using platform helper functions mentioned https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… (make sure your platform has implemented all the mandatory hooks). Hope this helps thanks Manish ________________________________ From: Mohd Yusuf Abdul Hamid via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2022 02:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ? Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

3 years, 8 months

2
1
0 0

What Doc / NDA doc do I need when I want to add a new platfrom in TF-A / OPTEE? (i.e., RK3566 )

by 起飞的老杨

Hello, Everyone, If I want to add a new platform support in TF-A for RK3566 as an example, what Documentation do I need to read. Using RK3399 as a contrast ( because most of RK3399 doc is opened in internet ), we already know this SoC is supported in OPTEE and TF-A. And I can get RK3399 Docs:* TRM V1.3 Part 1*, T*RM V1.3 Part2*, *TRM V1.4 Part 1*, *Datasheet V2.1*. I can see in *TRM chapter 16 System Security, *there are some descriptions about system security, and references to other system registers, like *SGRF, *etc, but it still seems to me insufficiently ( No SGRF description ) to finish a full support platform implementation in TF-A. Some people said I need to sign an NDA with Rockchip to get Security related part docs. But when I reach to Rockchip, they said all docs are opened already, No NDA options. When I talked to one partner/distributor of Rockchip, only security related doc is also some doc I can find on internet. So I am curious and confused, can I, as a third party developer, develop a new platform implementation for TF-A / OPTEE ( specially for Rockchip Platform )? Thanks

3 years, 8 months

2
2
0 0

How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Mohd Yusuf Abdul Hamid

Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

3 years, 8 months

1
0
0 0

Re: GIC-600 errata 1717652: missed wake requests

by Bipin Ravi

Hi Okash, In TF-A project, we haven't supported errata patches for system IP's like GIC-600 until now. We typically support Cat B errata patches for Arm CPU implementations that are made public. Additionally we also support DSU errata patches for the TF-A supported CPUs as applicable. But we are more than happy to support any code reviews required for the implementation of the below said errata. Thanks, Bipin -----Original Message----- From: tf-a-request(a)lists.trustedfirmware.org <tf-a-request(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 6:00 PM To: tf-a(a)lists.trustedfirmware.org Subject: TF-A Digest, Vol 37, Issue 16 1. GIC-600 errata 1717652: missed wake requests (Okash Khawaja) ---------------------------------------------------------------------- Message: 1 Date: Thu, 27 Jan 2022 13:36:32 +0000 From: Okash Khawaja <okash(a)google.com> Subject: [TF-A] GIC-600 errata 1717652: missed wake requests To: tf-a(a)lists.trustedfirmware.org Message-ID: <CAGjWKv6TTLVvF7GfsmY76QFjSzcSX8DqPuPukJQAOH-AqAvuLg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash ------------------------------ Subject: Digest Footer TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-A Digest, Vol 37, Issue 16 ************************************

3 years, 9 months

2
1
1 0

GIC-600 errata 1717652: missed wake requests

by Okash Khawaja

Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash

3 years, 9 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020Introduction of Arm CCA Context ManagementSession Presented by: Manish Pandey, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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   (changed) When: Thu Jan 27, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 9 months

1
0
1 0

TF-A Technical Forum Session Agenda this week

by Joanna Farley

Agenda for Session on 27th January 2020 * Introduction of Arm CCA Context Management * Session Presented by: Manish Pandey, Soby Mathew and Zelalem Aweke * Details: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. 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://www.trustedfirmware.org/meetings/tf-a-…> 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 9 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020introduction of Arm CCA Context ManagementSession Presented by: Manish Pandy, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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   (changed) When: Thu Jan 27, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 9 months

1
0
0 0

RFC for context management refactoring in TF-A

by Soby Mathew

Hello Everyone, We have a proposal to refactor the Context management framework in TF-A and an RFC is pushed for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13651 . The abstract of the RFC is given below: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. The plus point here is that many of the design principles are already adhered to in one way or other in the current the implementation so much of the work can be done in an incremental fashion without much disruption. Along with @Zelalem Aweke<mailto:Zelalem.Aweke@arm.com> and @Manish Pandey2<mailto:Manish.Pandey2@arm.com>, we hope to discuss the this RFC and how this translates to code changes in TF-A during the Tech Forum this week. Best Regards Soby Mathew

3 years, 9 months

1
0
0 0

About arm_validate_ns_entrypoint in arm_pm.c

by Ming Huang

Hi, arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas. It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space. In my mind, the kernel should guarantee the validity of entry point. So why this check is need? Thanks, Ming

3 years, 9 months

3
3
0 0

imx8mm-evk does not boot kernel 5.16 with mainline TF-A

by Fabio Estevam

Hi, I am running U-Boot 2022.01 on imx8mm-evk. If I build the NXP vendor-based TF-A (imx_5.4.47_2.2.0) I am able to boot kernel 5.16 just fine. However, if I use the upstream TF-A (v2.5 or v2.6), the kernel fails to boot most of the attempts. Peng, Jacky, Could you please try booting kernel 5.16 + U-Boot 2022.01 built with TF-A v2.6? What is missing in upstream TF-A to be able to boot kernel 5.16? Thanks, Fabio Estevam

3 years, 9 months

2
1
0 0

fw update & anti-rollback versioning

by Etienne CARRIERE

Dear all, (and may the new year be happy to you and your beloved) In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements: Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to. Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request. Req3: The version field should be present even if the FIP does not contain image certificates. Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates. Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A? Best regards, Etienne Carriere ST Restricted

3 years, 9 months

4
6
0 0

TF-A (inc Hafnium) Tech Forum this week

by Joanna Farley

Hi Everyone, Welcome to 2022! To start off this year’s Tech Forum’s we will use the session this week to follow up on two ongoing email list discussion subjects: * Hafnium Build and Tooling Options. * Discussion led by Olivier Deprez. * Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> * Firmware Update and Anti-Rollback Versioning * Discussion led by Manish Badarkhe and Manish Pandey2 * An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> If you don’t have the invite which just been updated the meeting details are: TF-A Tech Forum Thursday, January 13⋅4:00 – 5:00pm GMT 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…> Thanks all Joanna

3 years, 9 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum The Tech Forum this week will cover two discussion subjects:Hafnium Build and Tooling Options.  Discussion led by Olivier Deprez.Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… Update and Anti-Rollback VersioningDiscussion led by Manish Badarkhe and Manish Pandey2An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… 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   (changed) When: Thu Jan 13, 2022 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 Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… 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

3 years, 9 months

1
0
0 0

MISRA C compliance spreadsheet access permission

by Lim, Jit Loon

Hi TF-A committee, We are trying to access to the MISRA C spreadsheet mentioned over here. [cid:image001.jpg@01D806BE.A535F7C0] https://developer.trustedfirmware.org/file/download/lamajxif3w7c4mpjeoo5/PH… However, we are facing issue to open the spreadsheet and we are getting "Invalid Authorization". [cid:image002.jpg@01D806BE.A535F7C0] After we click on the "Continue", the website show Restricted File and we have no access permission. [cid:image003.jpg@01D806BE.A535F7C0] Thus, we would like to get your help to assist us on how to obtain the spreadsheet. Hope to hear from you soon. Thanks Best Regards JL Lim (Benjamin)

3 years, 9 months

2
2
0 0

A problem about assert failed in TF-A

by Chenxu Wang

Hi all, I am running FVP with 2CPUs, Cactus SP (SEL1), Hafnium (SEL2) and KVM VHE. Sometimes I send the "FFA_MSG_SEND_DIRECT_REQ" smc call from KVM (I fill 0x8400006f in x0, then VMID and SP ID in x1, let x2 as 0). It says assert failed, like this: ASSERT: lib/el3_runtime/aarch64/context_mgmt.c:651 BACKTRACE: START: assert 0: EL3: 0x4005cac 1: EL3: 0x400323c 2: EL3: 0x400620c 3: EL3: 0x400e180 4: EL3: 0x4005a94 BACKTRACE: END: assert After I check the bl31.dump, I notice that: when services/std_svc/spmd/spmd_main.c sends the FFA call (from NS to S) via "spmd_smc_forward(smc_fid, secure_origin,x1, x2, x3, x4, handle)", it will go to cm_el1_sysregs_context_restore(secure_state_out) and cm_el2_sysregs_context_restore(secure_state_out), then it will assert the cm_get_context(). it gets the NULL context, so assert failed. Before the problem appeared, I have modified many codes on a dirty TF-A v2.4 (commit hash is 0aa70f4c4c023ca58dea2d093d3c08c69b652113), Hafnium and TF-A-TESTS. I also mail with Hafnium MailList, they consider it can be a problem in EL3. Such assert is NOT ALWAYS failed. I mean, maybe when I run FVP and send "smc" now, it is failed. But when I shut down, run FVP, and send the same instruction with the same parameter again, it is OK. I want to know, what is the possible reasons for suddenly losing the secure context. Can you give me some advice on debugging? e.g., where should I check? Need I provide more info? Sincerely, Wang

3 years, 10 months

3
4
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 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() ________________________________________________________________________________________________________ *** CID 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() 170 171 mmio_write_32(base + SDMMC_POWER, 172 SDMMC_POWER_PWRCTRL_PWR_CYCLE | sdmmc2_params.dirpol); 173 mdelay(POWER_CYCLE_DELAY); 174 175 if (sdmmc2_params.vmmc_regu != NULL) { >>> CID 374565: Error handling issues (CHECKED_RETURN) >>> Calling "regulator_enable" without checking return value (as is done elsewhere 6 out of 7 times). 176 regulator_enable(sdmmc2_params.vmmc_regu); 177 } 178 179 mdelay(VCC_POWER_ON_DELAY); 180 181 mmio_write_32(base + SDMMC_POWER, sdmmc2_params.dirpol); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 10 months

1
0
0 0

How to change the address of region "RAM" in BL31?

by Chenxu Wang

Hi all, I want to add some big data structures in BL31 (e.g., create a large uint32_t array). Also, I reserve a secure memory space (assume it is 0xa000_0000 - 0xb000_0000) by configuring TZASC. Now, the BL31 says build/fvp/debug/bl31/bl31.elf section `.bss' will not fit in region `RAM' aarch64-none-elf-ld: BL31 image has exceeded its limit. aarch64-none-elf-ld: region `RAM' overflowed by 458752 bytes It looks like that the previous RAM cannot hold my big data structures. If I want to add my reserved region into RAM (so I may allocate these data into the reserved region), what should I do? Sincerely, Wang

3 years, 10 months

2
1
0 0

Re: [TF-A] [TF-M] Tip on cloning TF-M on OS X Monterey

by Gyorgy Szing

Hi, Please allow me to add some more details. Also posting to the TF-A list, as all tf.org repositories are affected. The root cause of this issue is OpenSSH dropping support for SHA-1 RSA signatures with the 8.8 release, and thus any OS (or git client) coming with a recent version is affected. I.e. the newest git for windows is affected too, and so are “top notch” Linux distributions like Arch. For details see the “Potentially-incompatible changes” chapter here: https://www.openssh.com/releasenotes.html As the above page states “Incompatibility is more likely when connecting to older SSH implementations…”, and thus a server-side update would eliminate the problem. Till that happens the page above list multiple client-side workarounds. (It is possible to amend the ssh config in a way that fixes all repositories.) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: December 15, 2021 13:06 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Tip on cloning TF-M on OS X Monterey I recently switched to a new MBP that ships with OS X Monterey, and on both 12.0 and 12.1 (released this week) git clone seems to be broken when you're using HTTP rather than SSH: digital envelope routines:CRYPTO_internal:bad key length In order to clone TF-M, I had to make the following changes. 1. Add these details to $HOME/.ssh/config (microbuilder being my github username, associated with my TF-M account): Host trustedfirmware.org<http://trustedfirmware.org> User microbuilder Hostname review.trustedfirmware.org<http://review.trustedfirmware.org> Port 29418 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes 2. Then try to clone with: $ git clone trustedfirmware.org:/TF-M/trusted-firmware-m.git This fails, however, since it tries to clone tf-m-tests.git, so: 3. Edit lib/ext/tf-m-tests/fetch_repo.cmake, changing: FetchContent_Declare(tfm_test_repo GIT_REPOSITORY trustedfirmware.org:TF-M/tf-m-tests.git # GIT_REPOSITORY https://git.trustedfirmware.org/TF-M/tf-m-tests.git GIT_TAG ${TFM_TEST_REPO_VERSION} GIT_PROGRESS TRUE ) This let me at least clone TF-M until the issues with HTTP-based cloning are fixed. Hope this is useful to someone else working on OS X natively. Kevin

3 years, 10 months

1
0
0 0

FCONF warning for TOS_FW_CONFIG

by Yann Gautier

Hi, On STM32MP1, we'd like BL2 to be agnostic of what BL32 is in the FIP. It can be either OP-TEE or TF-A SP_min. But on STM32MP1, SP_min needs a device tree file (TOS_FW_CONFIG_ID), whereas OP-TEE doesn't use this separate DT image. As TOS_FW_CONFIG_ID is in list of images to be loaded by BL2, we then have a warning message in case OP-TEE is used: WARNING: FCONF: Invalid config id 26 I'd like to silence this warning with this kind of patch: diff --git a/lib/fconf/fconf_dyn_cfg_getter.c b/lib/fconf/fconf_dyn_cfg_getter.c index 25dd7f9eda..f7e9834c3b 100644 --- a/lib/fconf/fconf_dyn_cfg_getter.c +++ b/lib/fconf/fconf_dyn_cfg_getter.c @@ -51,7 +51,11 @@ struct dyn_cfg_dtb_info_t *dyn_cfg_dtb_info_getter(unsigned int config_id) } } - WARN("FCONF: Invalid config id %u\n", config_id); + if (config_id == TOS_FW_CONFIG_ID) { + VERBOSE("FCONF: No TOS_FW_CONFIG image\n"); + } else { + WARN("FCONF: Invalid config id %u\n", config_id); + } return NULL; } I can change the VERBOSE message to INFO. Do you think it is OK if I push the patch? Thanks, Yann

3 years, 10 months

2
6
0 0

Cancelling Tech-Forums 16th and 30th December 2021

by Joanna Farley

I’m not sure if the cancellations have been sent from the trustedfirmware.org calendar system so confirming that they are cancelled to the list. Next scheduled Tech Forum is 13th January 2022. Joanna

3 years, 10 months

1
0
0 0

How to load some images in BL31?

by Chenxu Wang

Hi all, I want to load a specific image in BL31. But when I call load_auth_image(). It says "in function `load_image': trusted-firmware-a/common/bl_common.c:87: undefined reference to `plat_get_image_source'" Also, the io_read, io_size and etc. are undefined reference. I find other BL files (bl1, bl2) will call the load_auth_image() in their main functions or sub-functions. If I want to implement it on BL31, what should I do? Should I modify the Makefile? Sincerely, Wang

3 years, 10 months

2
1
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Hi Everyone, this is the TF-A Tech Forum meeting agenda for this week. Thanks Joanna Subject: ‘Measured Boot Driver - refactor and Critical Data measurement design’ Presented by: Manish Badarkhe 1. A brief overview of Measured Boot driver refactoring done in TF-A Bootloader 2. Discuss a few gaps observed in the Measured Boot driver and patches up-streamed for it 3. Discuss the list of critical data observed in TF-A firmware and its measurement design From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 2 December 2021 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

3 years, 11 months

1
0
0 0

Trusted Firmware version 2.6 is now available

by Bipin Ravi

Hi all, We are pleased to announce the formal release of Trusted Firmware-A version 2.6, Trusted Firmware-A Tests version 2.6, Hafnium version 2.6 and TF-A OpenCI Scripts 2.6 Releases involving the tagging of multiple sub repositories. These went live on 24th November 2021. Notable Features of the Version 2.6 Release across repositories are as follows: * v8-R64 Upstream support, trusted-boot (BL1) only * RME patches (4 world support) * Hunter & Hayes CPU support * Demeter (Makalu ELP for Infra) CPU support * ARM v9.0-A ETE V1.0 * ARM v9.1-A ETE V1.1 * Armv9 RME support * Generic Firmware Update support * Measured Boot Enhancements * MPMM AMU support SME (Mortlach) for non-secure world (FEAT_SME) * Security hardening LLVM/clang support. * FF-A v1.1 notifications support. * FF-A v1.1 interrupt handling support. * S-EL0 partitions (through VHE in the secure world). * SPM support for saving/restoring the normal world SVE live state. * Build system update to LLVM/Clang 12. * Updates to FF-A Setup and discovery. * FF-A compliance fixes. * Threat model introduced for SPMC at SEL2 * Eight new partner and Arm platforms support added Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes the previous release. The test plan and results [4] for the v2.6 release captures the release test activities. TF-A [5], TF-A Test [6], Hafnium [7] and TF-A OpenCI Scripts [8] repositories are available [1] https://trustedfirmware-a.readthedocs.io/en/v2.6/ [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.6/ [4] https://confluence.arm.com/display/BSGSoftware/TF-A+v2.6+Test+Plan+and+Resu… [5] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6 [6] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.6 [7] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.6 [8] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.6 Thanks & best regards, [cid:image001.jpg@01D7E120.C34F0DA0] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Bipin.Ravi@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

3 years, 11 months

1
0
0 0

Linux as BL33

by Ramon Fried

Hi. I'm trying to run on our new platform Linux as BL33, preloaded to DDR. currently simulated over QEMU. I think that BL31 started BL33 in EL0, which cause problems: QEMU outputs this message: (complete log below) Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000 What could I have done wrong in the configuration that caused it ? What should I check ? Thanks ! Ramon. NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL1: Built : 14:53:02, Nov 21 2021 INFO: BL1: RAM 0x15500000 - 0x15513000 WARNING: BL1: neoverse_n1: CPU workaround for 1946160 was missing! INFO: BL1: Loading BL2 INFO: Using mmap INFO: Using FIP INFO: Loading image id=1 at address 0x14300000 INFO: Image id=1 loaded: 0x14300000 - 0x143052d1 INFO: bl1_mem_layout->total_base = 0x14000000x NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x14300000 INFO: SPSR = 0x3c5 Exception return from AArch64 EL3 to AArch64 EL1 PC 0x14300000 INFO: BL1 inherited memory layout: 0x14000000 [size = 22020096] NOTICE: BL2: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL2: Built : 14:53:02, Nov 21 2021 INFO: BL2: Skip loading image id 23 INFO: BL2: Doing platform setup INFO: BL2: Loading image id 3 INFO: Using mmap INFO: Using FIP INFO: Loading image id=3 at address 0x800000000 INFO: Image id=3 loaded: 0x800000000 - 0x8000080a9 INFO: BL2: Skip loading image id 5 Taking exception 13 [Secure Monitor Call] ...from EL1 to EL3 ...with ESR 0x17/0x5e000000 ...with ELR 0x14302a04 ...to EL3 PC 0x5400 PSTATE 0x3cd NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x800000000 INFO: SPSR = 0x3cd Exception return from AArch64 EL3 to AArch64 EL3 PC 0x800000000 INFO: Boot BL33 from 0x800080000 for 0 Bytes NOTICE: BL31: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL31: Built : 14:53:04, Nov 21 2021 INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 63 INFO: BL31: Initializing runtime services WARNING: BL31: neoverse_n1: CPU workaround for 1946160 was missing! INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x800080000 INFO: SPSR = 0x0 Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000 Taking exception 1 [Undefined Instruction] ...from EL0 to EL1 ...with ESR 0x18/0x6232c061 ...with ELR 0x8000b7164 ...to EL1 PC 0x400 PSTATE 0x3c5 Taking exception 4 [Data Abort]

3 years, 11 months

2
2
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling TF-A Tech Forum this week as the team have nothing to present. We expect to have a topic for December 2nd." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Nov 18, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 11 months

1
0
0 0

Re: [TF-A] Missing CPU workaround warning message

by Varun Wadekar

Hi Pali, My understanding of the errata reporting mechanism is that some erratas are always checked during CPU boot. If the corresponding MACRO (ERRATA_A53_*) is disabled, then the ERRATA_MISSING code is reported. I would be concerned if the CPU is affected by the errata. If the errata needs to be enabled, the fix would be to enable the ERRATA_A53_* from the platform makefile. Hope this helps. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pali Rohár via TF-A Sent: Wednesday, July 7, 2021 9:11 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Bipin Ravi <Bipin.Ravi(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Konstantin Porotchkin <kostap(a)marvell.com>; Marek Behún <marek.behun(a)nic.cz> Subject: Re: [TF-A] Missing CPU workaround warning message External email: Use caution opening links or attachments Hello! Could somebody from TF-A helps with these two topics? I would really need to know if "missing errata warnings" debug message is some critical and needs to be fixed (and how?) or it is just a debug message and therefore should not be a warning... On Monday 28 June 2021 17:11:18 Pali Rohár wrote: > On Monday 28 June 2021 14:03:06 Olivier Deprez wrote: > > Hi, > > > > Is the question strictly related to this platform not implementing the mentioned errata (for which a platform change can be emitted)? > > Hello! The first question is if this is an issue that CPU workaround > is missing. And if yes (which seems to be) how big issue it is? And > how to resolve it? > > > Or is it more generally that those "missing errata warnings" are not printed in release mode? > > Assuming the latter, it looks to me it is the integrator mistake to not include the appropriate mitigations at development phase (hence while using debug mode for building TF-A). > > Then when the device is deployed (hence most often built for release mode), if this message is printed it is an indication for a malicious agent that such attack vector through mis-implemented errata is possible. So the consequence is possibly even worst than just "missing" to include the errata. > > > > Other TF-Aers (Bipin?) may have other opinions? > > And this is a second question. If missing CPU workaround is an issue, > should not be it printed also in release build? > > Also I see that in release builds are omitted not only messages about > missing CPU workarounds, but basically _all_ warning messages. But > notice messages are _not_ omitted. Which seems strange as in most > cases notice message has lower priority than warning message. > > > > > Regards, > > Olivier. > > > > ________________________________________ > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > Pali Rohár via TF-A <tf-a(a)lists.trustedfirmware.org> > > Sent: 28 June 2021 15:36 > > To: tf-a(a)lists.trustedfirmware.org > > Cc: Konstantin Porotchkin; Marek Behún > > Subject: [TF-A] Missing CPU workaround warning message > > > > Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug > > mode then at runtime it prints following warning messages: > > > > WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing! > > WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing! > > > > These lines are not printed in non-debug mode. It is an issue? > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > sts.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01 > > %7Cvwadekar%40nvidia.com%7Cb3605175f552468740e708d941836783%7C43083d > > 15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612854914595696%7CUnknown%7C > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > > VCI6Mn0%3D%7C1000&sdata=%2FW6HuFPYQCD5ECIA%2FZZxhm5ti5HYILNlsWTz > > moJ7L8E%3D&reserved=0 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

3 years, 11 months

6
17
0 0

Re: [TF-A] PSCI lock contention

by Varun Wadekar

<Adding TF-A mailing list to the discussion> Thanks, Soby. I agree that this needs to be re-evaluated for platforms. I think we should introduce an option to disable them, if required. We plan to try some more experiments and hopefully remove the locks at least for Tegra platforms. Looking forward to the elaborate answer. From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Tuesday, 2 November 2021 10:18 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Dan Handley <Dan.Handley(a)arm.com> Cc: Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Subject: RE: PSCI lock contention External email: Use caution opening links or attachments Hi Varun, The short answer is that the locks are used to differentiate the last-CPU-to-suspend and similarly first-CPU-to-powerup at a given power domain level. Now, recent CPU features like DynamIQ means that we don't need to do this differentiation upto cluster level which TF-A hasn't optimized for yet AFAICS. I am happy to elaborate further , but could you please send the query to the TF-A mailing list as I would prefer this discussion to happen in the open if possible. Best Regards Soby Mathew From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 01 November 2021 20:14 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>> Subject: PSCI lock contention Hi, We were trying performance benchmarking for CPU_SUSPEND on Tegra platforms. We take all CPU cores to CPU_SUSPEND and then wake them up with IPI - all at once and in serial order. From the numbers, we see that the CPUs powering up later take more time than the first one. We have narrowed the most time consumed to the PSCI locks - documented at docs/perf/psci-performance-juno.rst. Can you please help me understand why these locks were added? As a quick experiment we tried the same benchmarking *without* the locks and the firmware does not blow up, but I would like to understand the impact from the analysis on Juno (docs/perf/psci-performance-juno.rst) Happy to hop on a call to discuss further. Thanks. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

3 years, 11 months

2
8
0 0

Re: [TF-A] Trusted Firmware-A v2.6 release activities in November

by Joanna Farley

TF-A Community, Just a reminder we are looking to freeze the tree for release activities starting Monday. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Monday, 1 November 2021 at 12:41 To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Trusted Firmware-A v2.6 release activities in November TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No TF-A Tech Forum scheduled this week so cancelling." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Nov 4, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 12 months

2
1
0 0

FW: Two issues in Qemu port docs

by Joanna Farley

Forwarded on to TF-A Mail list. Seems postings from people with gmail.com email domains get automatically rejected, sorry Ramon not sure if that can be addressed. Joanna On 03/11/2021, 14:20, "Ramon Fried" <rfried.dev(a)gmail.com> wrote: Hi. I'm trying to run the example in TF-A documentation. I found two problems. First, the files: "tee-header_v2.bin, tee-pager_v2.bin, tee-pageable_v2.bin" are not provided as binary downloads, and instructions on how to get them are missing. turn's out you need to build optee, but this step is skipped if you choose to download the QEMU_EFI.fd from Linaro. Second, after following the instructions step by step resulted in the following error: qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon' -initrd rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL1: Built : 13:12:39, Nov 3 2021 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL2: Built : 13:12:42, Nov 3 2021 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL31: Built : 13:12:45, Nov 3 2021 read access to unsupported AArch64 system register op0:3 op1:0 crn:12 crm:12 op2:4 This occurs on Qemu 5.0 and also 6.0 Thanks, Ramon.

3 years, 12 months

2
1
0 0

Trusted Firmware-A v2.6 release activities in November

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 12 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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 373791: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 646 in usb_core_receive() ________________________________________________________________________________________________________ *** CID 373791: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 646 in usb_core_receive() 640 ep->is_in = false; 641 ep->num = num; 642 643 if (num == 0U) { 644 pdev->driver->ep0_start_xfer(hpcd->instance, ep); 645 } else { >>> CID 373791: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "(*pdev->driver->ep_start_xf...". 646 pdev->driver->ep_start_xfer(hpcd->instance, ep); 647 } 648 649 return USBD_OK; 650 } 651 ** CID 373790: Null pointer dereferences (FORWARD_NULL) /drivers/usb/usb_device.c: 182 in usb_core_set_config() ________________________________________________________________________________________________________ *** CID 373790: Null pointer dereferences (FORWARD_NULL) /drivers/usb/usb_device.c: 182 in usb_core_set_config() 176 } else if (cfgidx != pdev->dev_config) { 177 if (pdev->class != NULL) { 178 usb_core_ctl_error(pdev); 179 return; 180 } 181 /* Clear old configuration */ >>> CID 373790: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "pdev->class". 182 pdev->class->de_init(pdev, pdev->dev_config); 183 /* Set new configuration */ 184 pdev->dev_config = cfgidx; 185 /* Set configuration and start the USB class */ 186 if (pdev->class->init(pdev, cfgidx) != 0U) { 187 usb_core_ctl_error(pdev); ** CID 373789: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 684 in usb_core_transmit() ________________________________________________________________________________________________________ *** CID 373789: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 684 in usb_core_transmit() 678 ep->is_in = true; 679 ep->num = num; 680 681 if (num == 0U) { 682 pdev->driver->ep0_start_xfer(hpcd->instance, ep); 683 } else { >>> CID 373789: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "(*pdev->driver->ep_start_xf...". 684 pdev->driver->ep_start_xfer(hpcd->instance, ep); 685 } 686 687 return USBD_OK; 688 } 689 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

ARM Trusted memory Resolution

by IS20 Boaz Baron

Hi all, What is the resolution for secure memory space with the Trust zone? Is it dependent on the MMU resolution? Means, for example, If my MMU can set a range of 16 KB so can I set that range as a trusted zone as well? P.S. I have ARM A35 (I am not sure but I think my MMU supports a resolution of 32KB) You are welcome to comment if I have any mistakes Thanks a lot, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years

1
0
0 0

CFI in tf-a

by chen feng

I want to know if we have a chance to support the compiler-based CFI(eg clang cfi, kernel support it.) function in tf-a. I want to know that is anyone doing this, or if everyone is interested in this? Cheers, Feng

4 years

2
1
0 0

TF-A Tech Forum Agenda: Thu 21st October 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for 21st October 2021 16:00 – 17:00 (BST). Agenda: * Title: Realm Management Extension (RME) Granule Protection Table (GPT) Overview * Presented by: John Powell * Summary: Following on from the RME Overview session on 23rd September this session will provide more details of the Granule Protection Table (GPT) support recently upstreamed and the session will cover: 1. Overview of what GPT is 2. How it works 3. How it's configured and organized 4. Table initialization in TFA and why we do it this way 5. Runtime initialization and granule transition service ========================== If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years

1
0
0 0

Re: [TF-A] TFA affinity power level

by Madhukar Pappireddy

Hi HPChen 1. Can try setting PLATFORM_MAX_AFFLVL to MPIDR_AFFLVL2? I am assuming your platform has 1 cluster with 2 cores. 2. The project currently supports a limited number of platforms. The default test suite[1] contains several smaller test suites. The tests are designed to auto-detect critical features supported by the platform. Rather than fail, tftf will skip tests if a feature is not supported. Please refer to the documentation for the tf-a-tests project here: https://trustedfirmware-a-tests.readthedocs.io/en/latest/index.html [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/tests-s… Thanks, Madhukar -----Original Message----- From: TF-A <mailman-bounces(a)lists.trustedfirmware.org> On Behalf Of MS10 HPChen0 Sent: Tuesday, October 12, 2021 10:43 PM To: tf-a-owner(a)lists.trustedfirmware.org Subject: TFA affinity power level Hi, I'm Nuvoton software engineer. We have an A35 dual core platform. I ported the TFA for this platform. Now I want test the TFA on test suite. I have some questions. Please help to answer. Thanks! 1. If define 'PLATFORM_MAX_AFFLVL' to MPIDR_AFFLVL1. The tftf test only identify single core no matter 'PLATFORM_CORES_PER_CLUSTER' define to 2. How should I define 'PLATFORM_MAX_AFFLVL'? 2. How to select the test items? Should our platform need to pass all test items? Now I only test the tftf. I'm new for TFA. Please help. Thanks! Best regards, HPChen ________________________________ ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years

1
0
0 0

Support for passing 18 parameters to/from an SMC call in AArch64

by Rebecca Cran

I noticed TF-A currently supports passing in 4 parameters and returning up to 8. But SMCCC 1.1+ supports passing up to 18 and returning 18 in AArch64 mode, and passing in/out 8 in AArch32. I was wondering if there are any plans to add support for handling the full set of parameters? -- Rebecca Cran

4 years

2
2
0 0

BL1 loading BL2 but returned file length 4294967295

by 起飞的老杨

Hi I'm new to TF-A and OP Tee. While I am using qemu to start TF-A, I got BL1 detected and failed to load BL2, due to BL2 size out of bounds. I changed TF-A BL1 source code to show more information: diff --git a/common/bl_common.c b/common/bl_common.c index 2fcb5385d9..a6239a5257 100644 --- a/common/bl_common.c +++ b/common/bl_common.c @@ -110,7 +111,7 @@ static int load_image(unsigned int image_id, image_info_t *image_data) /* Check that the image size to load is within limit */ if (image_size > image_data->image_max_size) { - WARN("Image id=%u size out of bounds\n", image_id); + WARN("Image id=%u size(%lu, %u) out of bounds\n", image_id, image_size, image_data->image_max_size); io_result = -EFBIG; goto exit; } the log shows: NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.3():v2.3-dirty NOTICE: BL1: Built : 15:56:43, Apr 20 2020 INFO: BL1: RAM 0xe04e000 - 0xe056000 VERBOSE: BL1: cortex_a57: CPU workaround for 806969 was not applied WARNING: BL1: cortex_a57: CPU workaround for 813419 was missing! VERBOSE: BL1: cortex_a57: CPU workaround for 813420 was not applied VERBOSE: BL1: cortex_a57: CPU workaround for 814670 was not applied WARNING: BL1: cortex_a57: CPU workaround for 817169 was missing! INFO: BL1: cortex_a57: CPU workaround for disable_ldnp_overread was applied WARNING: BL1: cortex_a57: CPU workaround for 826974 was missing! WARNING: BL1: cortex_a57: CPU workaround for 826977 was missing! WARNING: BL1: cortex_a57: CPU workaround for 828024 was missing! WARNING: BL1: cortex_a57: CPU workaround for 829520 was missing! WARNING: BL1: cortex_a57: CPU workaround for 833471 was missing! WARNING: BL1: cortex_a57: CPU workaround for 859972 was missing! INFO: BL1: cortex_a57: CPU workaround for cve_2017_5715 was applied INFO: BL1: cortex_a57: CPU workaround for cve_2018_3639 was applied INFO: BL1: Loading BL2 VERBOSE: Using Memmap WARNING: Firmware Image Package header check failed. VERBOSE: Trying alternative IO VERBOSE: Using Semi-hosting IO INFO: Loading image id=1 at address 0xe01b000 WARNING: Image id=1 size(4294967295, 151552) out of bounds ERROR: Failed to load BL2 firmware. I'm using yocto (dunfell) + meta-arm to build / test TF-A + OP TEE under qemuarm64. meta-arm rev: c4f04f3fb66f8f4365b08b553af8206372e90a63 variables defined inside conf/local.conf ( for test ) 23 MACHINE ?= "qemuarm64" 25 26 INSANE_SKIP_pn-optee-examples = "ldflags" 27 COMPATIBLE_MACHINE_pn-optee-examples = "qemuarm64" 28 COMPATIBLE_MACHINE_pn-optee-os = "qemuarm64" 29 COMPATIBLE_MACHINE_pn-optee-client = "qemuarm64" 30 COMPATIBLE_MACHINE_pn-trusted-firmware-a = "qemuarm64" 31 32 TFA_PLATFORM = "qemu" 33 TFA_UBOOT = "1" 34 TFA_DEBUG = "1" 35 TFA_SPD = "opteed" 36 TFA_BUILD_TARGET = "bl1 bl2 bl31" 37 38 OPTEEMACHINE:qemuarm64 = "vexpress-qemu_armv8a" 39 OPTEEOUTPUTMACHINE:qemuarm64 = "vexpress" 40 41 UBOOT_MACHINE_qemuarm64 = "qemu_arm64_defconfig" I started qemu using following command line: BIOS=tmp/deploy/images/qemuarm64/bl1.bin \ KERNEL=tmp/deploy/images/qemuarm64/Image-qemuarm64.bin \ runqemu mydefined-image-core-image-dev-optee nographic -d \ qemuparams=" \ -machine secure=on \ -m 4096 \ -d unimp -semihosting -semihosting-config enable=on,target=native \ " Thanks

4 years

3
2
0 0

[RFC]: UFS patches

by Jorge Troncoso

Hi all, We made a few changes to the UFS driver. The proposed patches are posted here: https://review.trustedfirmware.org/q/topic:%22ufs_patches%22+(status:open%2… . The patches mainly consist of the below changes: 1. Delete asserts. Return error values instead. 2. Add retry logic and timeouts. 3. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands. Any feedback/comments on these patches would be greatly appreciated. Thanks! Jorge Troncoso

4 years

5
11
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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 373584: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 335 in gpt_validate_l0_params() /lib/gpt_rme/gpt_rme.c: 346 in gpt_validate_l0_params() ________________________________________________________________________________________________________ *** CID 373584: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 335 in gpt_validate_l0_params() 329 } 330 gpt_config.pps = pps; 331 gpt_config.t = gpt_t_lookup[pps]; 332 333 /* Alignment must be the greater of 4k or l0 table size. */ 334 l0_alignment = PAGE_SIZE_4KB; >>> CID 373584: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 335 if (l0_alignment < GPT_L0_TABLE_SIZE(gpt_config.t)) { 336 l0_alignment = GPT_L0_TABLE_SIZE(gpt_config.t); 337 } 338 339 /* Check base address. */ 340 if ((l0_mem_base == 0U) || ((l0_mem_base & (l0_alignment - 1)) != 0U)) { /lib/gpt_rme/gpt_rme.c: 346 in gpt_validate_l0_params() 340 if ((l0_mem_base == 0U) || ((l0_mem_base & (l0_alignment - 1)) != 0U)) { 341 ERROR("[GPT] Invalid L0 base address: 0x%lx\n", l0_mem_base); 342 return -EFAULT; 343 } 344 345 /* Check size. */ >>> CID 373584: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 346 if (l0_mem_size < GPT_L0_TABLE_SIZE(gpt_config.t)) { 347 ERROR("[GPT] Inadequate L0 memory: need 0x%lx, have 0x%lx)\n", 348 GPT_L0_TABLE_SIZE(gpt_config.t), 349 l0_mem_size); 350 return -ENOMEM; 351 } ** CID 373583: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 373583: Memory - corruptions (OVERRUN) /plat/imx/imx7/warp7/warp7_bl2_el3_setup.c: 110 in warp7_usdhc_setup() 104 105 zeromem(&params, sizeof(imx_usdhc_params_t)); 106 params.reg_base = PLAT_WARP7_BOOT_MMC_BASE; 107 params.clk_rate = 25000000; 108 params.bus_width = MMC_BUS_WIDTH_8; 109 mmc_info.mmc_dev_type = MMC_IS_EMMC; >>> CID 373583: Memory - corruptions (OVERRUN) >>> Overrunning struct type imx_usdhc_params_t of 16 bytes by passing it to a function which accesses it at byte offset 23. 110 imx_usdhc_init(&params, &mmc_info); 111 } 112 113 static void warp7_setup_usb_clocks(void) 114 { 115 uint32_t usb_en_bits = (uint32_t)USB_CLK_SELECT; ** CID 373582: Null pointer dereferences (NULL_RETURNS) /plat/intel/soc/common/socfpga_storage.c: 171 in socfpga_io_setup() ________________________________________________________________________________________________________ *** CID 373582: Null pointer dereferences (NULL_RETURNS) /plat/intel/soc/common/socfpga_storage.c: 171 in socfpga_io_setup() 165 166 result = io_dev_open(fip_dev_con, (uintptr_t)NULL, &fip_dev_handle); 167 assert(result == 0); 168 169 if (boot_source == BOOT_SOURCE_SDMMC) { 170 partition_init(GPT_IMAGE_ID); >>> CID 373582: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "get_partition_entry(a2)", which is known to be "NULL". 171 fip_spec.offset = get_partition_entry(a2)->start; 172 } 173 174 (void)result; 175 } 176 ** CID 373581: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 780 in gpt_init_l0_tables() /lib/gpt_rme/gpt_rme.c: 775 in gpt_init_l0_tables() ________________________________________________________________________________________________________ *** CID 373581: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 780 in gpt_init_l0_tables() 774 /* Iterate through all L0 entries */ 775 for (unsigned int i = 0U; i < GPT_L0_REGION_COUNT(gpt_config.t); i++) { 776 ((uint64_t *)l0_mem_base)[i] = gpt_desc; 777 } 778 779 /* Flush updated L0 tables to memory. */ >>> CID 373581: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 780 flush_dcache_range((uintptr_t)l0_mem_base, 781 (size_t)GPT_L0_TABLE_SIZE(gpt_config.t)); 782 783 /* Stash the L0 base address once initial setup is complete. */ 784 gpt_config.plat_gpt_l0_base = l0_mem_base; 785 /lib/gpt_rme/gpt_rme.c: 775 in gpt_init_l0_tables() 769 } 770 771 /* Create the descriptor to initialize L0 entries with. */ 772 gpt_desc = GPT_L0_BLK_DESC(GPT_GPI_ANY); 773 774 /* Iterate through all L0 entries */ >>> CID 373581: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 775 for (unsigned int i = 0U; i < GPT_L0_REGION_COUNT(gpt_config.t); i++) { 776 ((uint64_t *)l0_mem_base)[i] = gpt_desc; 777 } 778 779 /* Flush updated L0 tables to memory. */ 780 flush_dcache_range((uintptr_t)l0_mem_base, ** CID 373580: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 373580: Memory - corruptions (OVERRUN) /plat/imx/imx7/picopi/picopi_bl2_el3_setup.c: 104 in picopi_usdhc_setup() 98 99 zeromem(&params, sizeof(imx_usdhc_params_t)); 100 params.reg_base = PLAT_PICOPI_BOOT_MMC_BASE; 101 params.clk_rate = 25000000; 102 params.bus_width = MMC_BUS_WIDTH_8; 103 mmc_info.mmc_dev_type = MMC_IS_EMMC; >>> CID 373580: Memory - corruptions (OVERRUN) >>> Overrunning struct type imx_usdhc_params_t of 16 bytes by passing it to a function which accesses it at byte offset 23. 104 imx_usdhc_init(&params, &mmc_info); 105 } 106 107 static void picopi_setup_usb_clocks(void) 108 { 109 uint32_t usb_en_bits = (uint32_t)USB_CLK_SELECT; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Re: [TF-A] ATF F/w image Decryption support

by Sumit Garg

+ TF-A ML (for the benefit of other trying to use firmware encryption feature) Hi Promod, On Fri, 8 Oct 2021 at 00:09, pramod kumar <pramod.jnumca04(a)gmail.com> wrote: > Hi Sumit, > > This is Pramod, Presently working in Amazon Lab126. I'm working in ATF and > was going through your patch which provides f/w image encryption/decryption > support. > > commit 7cda17bb0f92db39d123a4f2a1732c9978556453 > Author: Sumit Garg <sumit.garg(a)linaro.org> > Date: Fri Nov 15 10:43:00 2019 +0530 > > drivers: crypto: Add authenticated decryption framework > > Add framework for autheticated decryption of data. Currently this > patch optionally imports mbedtls library as a backend if build option > "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated > decryption > using AES-GCM algorithm. > > Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> > Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271 > > I see that this support comes under DECRYPTION_SUPPORT macro hence can't > be used dynamically. I see the TBBR spec provides a flag for this which > could be used to exercise this feature dynamically- > [image: image.png] > > > Just wanted to understand that did you see any limitation to use this flag > for making this feature support dynamically? Or do you have any plan to > push follow up patches for this? > > Actually there are security concerns associated if we use an unsigned encryption flag in the header (see earlier discussions [1]). > If this feature is made available, with the help of "disable_auth" flag, > BL1 would be able to boot plane images even when TRUSTED_BOARD_BOOT is > enabled in development mode. > I agree here that it would be useful to have such a flag in development mode. For TRUSTED_BOARD_BOOT in development mode, I guess you are referring to DYN_DISABLE_AUTH. If yes then I think such a macro makes sense for encryption as well in order to disable decryption at runtime in development mode, patches are very much welcome. [1] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000288.html -Sumit > Regards, > Pramod >

4 years

1
0
0 0

[RFC]: Refactor measured boot patches

by Manish Badarkhe

Hi All, We have refactored/redesigned the existing measured boot driver present in the TF-A repo to support it with multiple backend driver(s) (for example, TCG Event Log, physical TPM, etc) instead of it being strongly coupled with the TCG Event Log driver. Proposed refactored patches are posted here: https://review.trustedfirmware.org/q/topic:%22refactor-mb%22+(status:open%2… Any feedback/comments on these patches are much appreciated. These patches mainly consist of the below changes: 1. Move image measurement in the generic layer, just after loading and authentication of the image. Previously, the platform layer was responsible for the measurement. For example, the Arm FVP platform layer was doing it as part of the post-load hook operation. 2. Measurement and recording of the images loaded by BL1. Previously, DTB config files loaded by BL1 were not part of measured at all. Also, it looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event log buffer/physical TPM/any other TPM backend instead of deferring these recordings to BL2. 3. Pass Event Log buffer information from BL1 to BL2 so that the TCG Event Log buffer initialised by BL1 extended further with the measurements taken by BL2. Note: These patches neither add any new functional backend driver for measured boot nor update any existing backend driver functionality (i.e. TCG Event Log driver). These changes only structured the measured boot code to provide a space to plug in any new backend driver(s) in future for the measured boot. Thanks, Manish Badarkhe

4 years

2
1
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling this weeks TF-A Tech Forum as we have no subjects/topics to present for this meeting. The TF-A project community is always looking for subjects/topics so if you have something to present/discuss please do reach out to me and we can schedule a session. Thanks all." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Oct 7, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years

1
0
0 0

Issue submitting changes for review at https://review.trustedfirmware.org

by Jorge Troncoso

Hi all, I tried submitting a change for review at https://review.trustedfirmware.org, but I ran into authentication issues. 1. First try (https): $ git push origin HEAD:refs/for/integration Username for 'https://review.trustedfirmware.org': jatron Password for 'https://jatron@review.trustedfirmware.org': remote: Unauthorized fatal: Authentication failed for ' https://review.trustedfirmware.org/TF-A/trusted-firmware-a/' I tried clicking "GENERATE NEW PASSWORD" in https://review.trustedfirmware.org/settings/, but I got the following error message: An error occurred Error 500 (Server Error): Internal server error Endpoint: /accounts/self/password.http 2. Second try (ssh): I got the following error message when I tried registering a new SSH key for use with Gerrit. This happened when I clicked "ADD NEW SSH KEY" in https://review.trustedfirmware.org/settings/. An error occurred Error 500 (Server Error): Internal server error Endpoint: /accounts/self/sshkeys The error message didn't stop the GUI from recording my key though. My new key was listed under "SSH keys" after the change. When I ran a git push command using ssh, I got the following error. $ git push ssh://jatron@review.trustedfirmware.org/TF-A/trusted-firmware-a HEAD:refs/for/integration jatron(a)review.trustedfirmware.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Am I doing something incorrectly? Any help would be much appreciated. If this is not the mailing list for these types of questions, please let me know so I can reroute my email to the proper destination. Thanks, Jorge Troncoso

4 years, 1 month

2
3
0 0

: Forthcoming UFS driver patches

by Jorge Troncoso

Hi all, I'm planning to submit a series of patches that aim to improve the robustness and reusability of the UFS code. The impacted files are drivers/ufs/ufs.c and include/drivers/ufs.h. The patches mainly consist of the below changes: 1. Delete asserts. Return error values instead. 2. Add retry logic and timeouts. 3. Remove infinite loops. 4. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands. 5. Add a function ufs_send_cmd() that can be reused in other places. ufs_send_cmd() calls four functions in sequence: get_utrd(&utrd), ufs_prepare_cmd(&utrd, ...), ufs_send_request(utrd.task_tag), and ufs_check_resp(&utrd, RESPONSE_UPIU). I wanted to give everyone visibility of what is coming up and hopefully start a discussion around this work. Any early input to help shape the design would be much appreciated. Thanks, Jorge Troncoso

4 years, 1 month

1
0
0 0

How to write a Trsuted Application?

by Chenxu Wang

Hi all, I want to write a TA which will be called from the Normal World and be handled by a specific Trusted OS. Currently, I am using 3 Cactus OS (provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial building cmd make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1 BL33=../tf-a-tests/build/fvp/debug/tftf.bin BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip I have created some EL3 services at services/std_svc, but have not created a TA. In my view, to call the TA, I think I should pass (1) the ID of the TA (but I am not sure how to get the ID) (2) several parameters, which may be loaded into registers. Here may be a calling process. ldr x0,=0xdeadbeef // loading ID ldr x1,=0x11111 // input parameters ldr x2,=0x22222 // input parameters smc #0 Then I think I should write a corresponding handler (of the TA) in Cactus OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA. However, I don't know how to do it. Can you provide some useful examples? Sincerely, Wang Chenxu

4 years, 1 month

3
4
0 0

TF-A Tech Forum Agenda: Thu 23rd September 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for 23rd September 2021 16:00 – 17:00 (BST). Agenda: * Title: Realm Management Extension (RME) Support in TF-A * Presented by: Zelalem Aweke * Summary: RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA). In this talk I will give a brief introduction to Arm CCA and RME. Then I will talk about the changes in TF-A to support RME that are expected to be part of the TF-A v2.6 release. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 1 month

1
0
0 0

Issue with @foss.st.com e-mail address

by Yann Gautier

Hello, Last Thursday we got an issue on our @foss.st.com mail server, preventing us from receiving mails. The issue was corrected, and I can now correctly receive mails, except the ones from trustedfirmware.org. Is there some kind of filtering on trustedfirmware.org side, as those addresses got error replies? I've tried to delete my yann.gautier(a)foss.st.com in the trusted firmware gerrit settings, to re-enter it again, but I cannot receive the verification e-mail. Could you check if @foss.st.com addresses are rejected somewhere? Thanks, Yann

4 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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 373165: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 467 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373165: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 467 in spm_vcorefs_get_vcore() 461 int spm_vcorefs_get_vcore(unsigned int gear) 462 { 463 int ret_val; 464 465 switch (gear) { 466 case 3: >>> CID 373165: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_0_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 467 ret_val = vcore_opp_0_uv; 468 case 2: 469 ret_val = vcore_opp_1_uv; 470 case 1: 471 ret_val = vcore_opp_2_uv; 472 case 0: ** CID 373164: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 471 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373164: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 471 in spm_vcorefs_get_vcore() 465 switch (gear) { 466 case 3: 467 ret_val = vcore_opp_0_uv; 468 case 2: 469 ret_val = vcore_opp_1_uv; 470 case 1: >>> CID 373164: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_2_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 471 ret_val = vcore_opp_2_uv; 472 case 0: 473 default: 474 ret_val = vcore_opp_3_uv; 475 } 476 return ret_val; ** CID 373163: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 469 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373163: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 469 in spm_vcorefs_get_vcore() 463 int ret_val; 464 465 switch (gear) { 466 case 3: 467 ret_val = vcore_opp_0_uv; 468 case 2: >>> CID 373163: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_1_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 469 ret_val = vcore_opp_1_uv; 470 case 1: 471 ret_val = vcore_opp_2_uv; 472 case 0: 473 default: 474 ret_val = vcore_opp_3_uv; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 1 month

1
0
0 0

Disable the EL2 hypervisor mode

by IS20 Boaz Baron

Hi all, I have a little question, how can I disable the hypervisor mode so EL2 will be just bridge to EL1 ns? (I mean without touching common ARM code only the platform-oriented code) 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.

4 years, 1 month

2
1
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No subjects to present this week so cancelling." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Sep 9, 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

4 years, 1 month

1
0
0 0

include/plat/common in project path?

by Yann Gautier

Hi, When I check the tf-static-checks for the FIP/FCONF series I pushed for STM32MP1, I have a failure: 1d204ee4a:plat/st/common/bl2_io_storage.c: ['tools_share/firmware_image_package.h should be in project group, after system group'] First I didn't understand the issue, as the file is in project group. But the issue is due to previous include: #include <plat/common/platform.h> As it is inside include/plat directory, it is seen as a platform include. For me the files in this include/plat/common directory are more project, but what is your point of view? If they are platform files, I should modify my series to reflect that. If they are project files, then the check-include-order.py script should be updated. Here is what could be the correction: diff --git a/script/static-checks/check-include-order.py b/script/static-checks/check-include-order.py index aaf84f1..53d355b 100755 --- a/script/static-checks/check-include-order.py +++ b/script/static-checks/check-include-order.py @@ -87,6 +87,8 @@ def inc_order_is_correct(inc_list, path, commit_hash=""): incs = collections.defaultdict(list) error_msgs = [] plat_incs = dir_include_paths("plat") | dir_include_paths("include/plat") + plat_common_incs = dir_include_paths("include/plat/common") + plat_incs.difference_update(plat_common_incs) libc_incs = dir_include_paths("include/lib/libc") Best regards, Yann

4 years, 1 month

1
0
0 0

Re: [TF-A] Secure boot without FIP

by Yann Gautier

On 7/28/21 10:50 AM, guillaume pivetta via TF-A wrote: > Hi, I’m trying to implement a secure boot on a STM32MP1 without using > the FIP file. > Hi Guillaume, Sorry for this very late reply. > 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. > That's quite an old software. If you can, I'd suggest you update the software to the version delivered by ST, based on a v2.4 label. The sources are available there: https://github.com/STMicroelectronics/arm-trusted-firmware And you should take the v2.4-stm32mp branch. In this software, FIP is available, and with a better support for TUSTED_BOARD_BOOT. > 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. > > If you can switch to a newer software with FIP, you can check: https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FIP Else, the page that could help you is there: https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_secure_boot If you need more help, the better is to use the links given at the bottom of the wiki pages: ST Support Center (https://community.st.com/s/onlinesupport) or ST Community MPU Forum (https://community.st.com/s/topic/0TO0X0000003u2AWAQ/stm32-mpus). Best regards, Yann

4 years, 2 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling TF-A Tech forum this week as we have no scheduled topic." 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 Aug 26, 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

4 years, 2 months

1
0
0 0

Re: [TF-A] Rethrow SError from EL3 to kernel on arm64

by Ming Huang

Hi, I did the test report SDEI to kernel with fatal severity in APEI / CPER while EL3 received SEA(SCR_EL3.EA = 1). Kernel will panic and print calltrace, but this calltrace was not the position where error occured(another word where throw SEA), instead calltrace in ghes.c. How can SDEI solution let kernel print calltrace at right position? For issue analysis, the right position calltrace is very useful. For ACPI firmware-first, we set SCR_EL3.EA = 1, although the solution rethrow EA back to kernel will suffer from some problems, but this solution can let kernel print calltrace at right position. Best Regards, Ming Huang On 5/25/21 8:08 PM, James Morse via TF-A wrote: > Hi Pali, > > I assume the aborts you are ignoring are precise! SError can be imprecise. > I guess these are due to some integration issue with the PCIe root-complex. You shouldn't > get aborts outside a RAS error. PCIe has DPC/eDPC and AER for signalling RAS errors - I > guess these aren't supported on your platform. > > > To emulte the synchronous/asynchronous exceptions means emulating what the CPU would do if > SCR_EL3.EA weren't set. I'm not sure how familiar you are with the CPU's exception model > and all its routing/masking controls. A short tour of what is involved: > (the numbered references are for DDI0487G.a, they may have moved in your version) > > > To emulate an exception you need to copy ESR_EL3, SPSR_EL3 and ELR_EL3 to the ESR, SPSR > and ELR of the target EL. You need to calculated new PSTATE and PC for SPSR_EL3 and > ELR_EL3. The way the CPU does this is described in the psuedocode in the arm-arm. See > AArch64.TakeException. This will involve reading SCTLR of the target EL. > For Synchronous-External-Abort, if the FnV bit is clear, you should copy FAR_EL3 to FAR of > the target EL too. > > There is a GPL implementation of some of these bits in the kernel's KVM code, but that is > probably of limited use due to the license. > > > To determine the target EL you need to examine the routing controls set by the lower ELs. > Synchronous Exceptions are the easiest as they can't be masked: > The routing rules are describe in D1.12.4 "Routing synchronous External Aborts" is a > little terse. It glosses over HCR_EL2.TGE that would also route the exception to EL2. > > For a synchronous-external-abort triggered by EL1 where HCR_EL2.TERR is not supported, or > clear: If the fault was at stage1, it goes to EL1, if the fault was at stage2, it goes to > EL2. There is nothing the ESR to tell you which it was as the CPU indicates this with the > target EL, which was overridden by SCR_EL3.EA. (The architecture doesn't expect you to be > re-injecting exceptions from EL3). > Pragmatically the best option is to allow HCR_EL2.AMO to route synchronous exceptions to > EL2 too. (this is a big hint that a hypervisor is managing errors for this exception > level). If ELR_EL3.S1PTW is set, this is definitely a stage2 fault, EL1 should never see > this bit set. > (Synchronous Exceptions can't be routed to a lower EL). > > > Synchronous errors were the easy one. Asynchronous error routing is described in D1.13.1 > "Asynchronous exception routing". You want to take note of HCR_EL2.{AMO, TGE}. But it can > also be masked by PSTATE.A of the target EL. (See D1.13.2 "Asynchronous exception masking"): > If SPSR_EL3.M is the target EL, SPSR_EL3.A would have masked SError. You cannot emulate > the exception if this bit is set. > If SPSR_EL3.M is lower than the target EL, then you can emulate the exception to the > target EL. > If SPSR_EL3.M is higher than the target EL, then SError is effectively masked, and you > cannot emulate the exception. > > > (I don't think HPFAR_EL2 needs to be set for these cases, but I'd need to check) > > > Finally, you still need something to do if you can't emulate the exception. Updating a > system log if you have one and rebooting is the only real option. > > > > Thanks, > > James > > > On 25/05/2021 11:08, Pali Rohár wrote: >> Hello! >> >> Platform is not ACPI based. PCIe core in some cases sends External >> Aborts to kernel which needs to be masked/ignored. I have not found a >> way how to reconfigure PCIE core to not send these aborts. >> >> In mentioned review is a link to kernel list where was discussion about >> custom kernel handlers to ignore some of EA. But this approach was >> rejected with information that TF-A should handle these aborts and >> ignores those which should not be propagated back to kernel. >> >> If I clear SCR_EL3.EA then aborts (including those which should be >> ignored) are sent to kernel and kernel makes them fatal. So this is not >> a solution. >> >> If I do not clear SCR_EL3.EA then in TF-A board/platform code I can >> implement check for aborts which needs to be ignored. But remaining >> aborts are not delivered to kernel and TF-A makes them fatal. Which is >> not correct too. >> >> So, what I need, is to route all External Aborts to TF-A, implement >> logic which ignores specific PCIE aborts and all remaining aborts needs >> to be propagated back to kernel like if SCR_EL3.EA is clear. >> >> So it means to implement some logic of abort injection. >> >> On Tuesday 25 May 2021 11:00:09 James Morse wrote: >>> Hi Guys, >>> >>> Does this platform need external-aborts to be routed to EL3? If not, you can clear >>> SCR_EL3.EA and be done with it. This allows the EL2 OS/Hypervisor to take control of the >>> routing of these exceptions. (which sounds like what you want) >>> >>> >>> Otherwise: >>> As Soby describes, the choices are SDEI or emulate the exception according to the arm-arm >>> psuedocode as if EL3 weren't implemented. This is best avoided as its difficult to get >>> right: you have to create a new PSTATE for the target exception level, and read the >>> routing controls to work out which exception level that is. >>> >>> As Achin says, emulating the exception isn't always possible as Asynchronous exceptions >>> can be masked. The hardware does this automatically when it takes an exception (e.g. irq). >>> (Linux unmask it again once its read the CPU state). >>> >>> This can leave you holding what may be an imprecise-asynchronous-abort in EL3, unable to >>> emulate the exception or proceed without causing any RAS error to become uncontained. >>> If you can't inject the emulated exception, the error still has to be handled at EL3. If >>> this is an ACPI system you can do a soft restart of the normal-world and present the error >>> via ACPI's BERT (boot error record table) which describes an error that happened in a >>> previous life. >>> >>> >>> If your platform is ACPI firmware-first, using SDEI will make life easier. You still need >>> to handle the 'SDEI masked' case, but it is a lot less likely to happen. Linux only does >>> this over power-management events that (may) disable the MMU. >>> >>> >>> (EL2 doesn't have any of these problems as errors are almost always contained by stage2, >>> and it has hardware features for injecting asynchronous exceptions, which cope with the >>> masking and deferring) >>> >>> >>> Thanks, >>> >>> James >>> >>> >>> On 25/05/2021 10:08, Achin Gupta wrote: >>>> Hi, >>>> >>>> The last time I checked injecting an SError from a higher to lower EL is a bad >>>> idea since the latter could be running with SErrors masked. >>>> >>>> EL3 could check this before injecting but then there is no consistent contract >>>> with the lower EL about reporting of these errors. SDEI does not suffer from the >>>> same problem. >>>> >>>> +James who knows more from the OS/Hypervisor perspective. >>>> >>>> cheers, >>>> Achin >>>> -------------------------------------------------------------------------------- >>>> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew >>>> via TF-A <tf-a(a)lists.trustedfirmware.org> >>>> *Sent:* 25 May 2021 09:59 >>>> *To:* Pali Rohár <pali(a)kernel.org> >>>> *Cc:* kabel(a)kernel.org <kabel(a)kernel.org>; tf-a(a)lists.trustedfirmware.org >>>> <tf-a(a)lists.trustedfirmware.org> >>>> *Subject:* Re: [TF-A] Rethrow SError from EL3 to kernel on arm64 >>>> [+tf-a list] >>>> Hi Pali, >>>> There are 2 philosophies for handing SError in the system, kernel first and >>>> firmware first. Assuming you want to stick with firmware first handling (i.e >>>> scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the >>>> kernel for delegating the error handling: SDEI and SError injection back to >>>> kernel. Upstream TF-A only supports SDEI at the moment. >>>> >>>> For SError injection back to lower EL, you have to setup the hardware state via >>>> software at higher EL in such a way that it appears that the fault was taken to >>>> the exception vector at the lower exception level. The pseudocode function >>>> AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an >>>> exception to an Exception level using AArch64 in Non-debug state. This behaviour >>>> has to replicated and it involves the higher EL setting up the PSTATE registers >>>> correctly and values in other registers for the lower EL (spsr, elr and fault >>>> syndrome registers) and jumping to the right offset point to by the vbar_elx of >>>> the lower EL. To the lower EL is appears as a SError has triggered at its >>>> exception vector and it can proceed with the fault handling. >>>> >>>> Best Regards >>>> Soby Mathew >>>> >>>>> -----Original Message----- >>>>> From: Pali Rohár <pali(a)kernel.org> >>>>> Sent: Monday, May 24, 2021 6:07 PM >>>>> To: Soby Mathew <Soby.Mathew(a)arm.com> >>>>> Subject: Rethrow SError from EL3 to kernel on arm64 >>>>> >>>>> Hello Soby! >>>>> >>>>> I have found following discussion in Armada 3720 PCIe SError issue: >>>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware- >>>> <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-> >>>>> a/+/1541/comment/ca882427_d142bde2/ >>>>> >>>>> TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler. >>>>> You wrote in that discussion: >>>>> >>>>> Ideally you need to signal the SError back to kernel from EL3 using >>>>> SDEI or inject the SError to the lower EL and the kernel can decide to >>>>> die or not. >>>>> >>>>> And I would like to ask you, could you help me with implementation of this >>>>> SError rethrow functionality? Because I have absolutely no idea how to do it >>>>> and catching all SErrors in EL3 is causing issues because some of them can be >>>>> handled and recovered by kernel. >>>> -- >>>> TF-A mailing list >>>> TF-A(a)lists.trustedfirmware.org >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>>> <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> >>> >

4 years, 2 months

2
6
0 0

[RFC] Realm Management Extension (RME) patches

by Zelalem Aweke

Hi All, We have upstreamed TF-A patches for Arm Realm Management Extension (RME) feature at: https://review.trustedfirmware.org/q/topic:%22za%252Ffeat_rme%22+(status:op…. Any reviews/comments are very much appreciated 🙂 RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA)<https://www.arm.com/why-arm/architecture/security-features/arm-confidential…>. The major changes with this extension include: * Two additional Security states, Root and Realm * Two additional physical address spaces, Root and Realm * The ability to dynamically transition memory granules between physical addresses spaces * Granule Protection Check mechanism More information about RME and Arm CCA can be found at [1] and [2]. [1] https://developer.arm.com/documentation/ddi0615/latest [2] https://developer.arm.com/documentation/den0125/latest Thanks, Zelalem

4 years, 2 months

1
0
0 0

TF-A Tech Forum Agenda: Thu 12th August 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 12th August 2021 16:00 – 17:00 (BST). Agenda: * Enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE – Presented by Raghupathy Krishnamurthy * Summary: Present and discuss enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE. The goal is to present an ARM server centric view point on the requirements in Secure World, the solution space explored to meet these requirements and why/how FF-A S-EL0 partition on hafnium using FEAT_VHE appear to fit these requirements. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 2 months

1
0
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Olivier Deprez

Hi Andrew, I have submitted the change as you have passed it through the ML as a base for the discussion. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/11002 The issue is acknowledged, we had a brief discussion internally as to how best to refactor if need be. It looks to us the main problem is that SPM-MM (pre-dating FF-A) has aged a bit and mixes standard and impdef func ids. e.g. MM is an Arm standard and only defines two func ids (0x84000040, 0x84000041) so it may just be a matter of updating SPM_MM_FID_MAX_VALUE to 0x41 such that MM related services go through. The other ids 0xX4000060, 61, 64, 65 are purely impdef for the SPM-MM to/from SP communication. Thus we may define SP_MM_FID_MIN_VALUE/SP_MM_FID_MAX_VALUE and a corresponding is_sp_mm_fid macro. This would avoid the clash with TRNG IDs (0xX4000050, 51, 52, 53). What do you reckon? Btw out of curiosity how did you discover this? Do you have a setup enabling both SPM_MM and TRNG_SUPPORT option? Or maybe this is because of Trusty SPD reuse of spm_mm_smc_handler? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 04 August 2021 22:50 To: Manish Pandey2 Cc: tf-a(a)lists.trustedfirmware.org; Jimmy Brisson; Andre Przywara Subject: Re: [TF-A] TRNG SMCs intercepted by SPM-MM I'm seeing server errors when I try "Generate Password" or setting the ssh key so I'm not sure how to push and authenticate. I've sent the patch directly to you, Manish, so the formatting doesn't get messed up and I don't know how to make git-send-email add it to a thread nicely.. On Wed, 4 Aug 2021 at 05:51, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org<http://developer.trustedfirmware.org> and review.trustedfirmware.org<http://review.trustedfirmware.org>. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io<http://trustedfirmware-a.readthedocs.io> Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org<http://review.trustedfirmware.org> If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 03 August 2021 22:32 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Andre Przywara <Andre.Przywara(a)arm.com<mailto:Andre.Przywara@arm.com>>; Jimmy Brisson <Jimmy.Brisson(a)arm.com<mailto:Jimmy.Brisson@arm.com>> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com<mailto:ascull@google.com>> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

2
2
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Manish Pandey2

Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org and review.trustedfirmware.org. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 August 2021 22:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Andre Przywara <Andre.Przywara(a)arm.com>; Jimmy Brisson <Jimmy.Brisson(a)arm.com> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

2
1
0 0

TRNG SMCs intercepted by SPM-MM

by Andrew Scull

I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog

4 years, 2 months

1
0
0 0

Issue with Xilinx ZynqMP FPGA loading with ATF v2.5

by Robert Hancock

After updating to ATF v2.5 on the Xilinx ZynqMP platform, I was having issues with the FPGA PL logic not loading successfully from U-Boot, it was failing with this error: PL FPGA LOAD failed with err: 0x000007d6 which is PM_RET_ERROR_TIMEOUT. The following commit introduced the timeout: commit 4d9b9b2352f9a67849faf2d4484f5fcdd2788b01 Author: Tejas Patel <tejas.patel(a)xilinx.com> Date: Thu Feb 25 02:37:09 2021 -0800 plat: xilinx: Add timeout while waiting for IPI Ack Return timeout error if, IPI is not acked in specified timeout. Signed-off-by: Tejas Patel <tejas.patel(a)xilinx.com> Change-Id: I27be3d4d4eb5bc57f6a84c839e2586278c0aec19 The timeout value (TIMEOUT_COUNT_US) is set to 0x4000 (16384) usec, which appears to be too short for the FPGA loading operation (at least on the ZCU102 board with XCZU9EG device), causing it to always timeout. Increasing the timeout to 0xF4240 usec (i.e. 1 second) fixes the issue, though some lower value may also be sufficient. -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com

4 years, 2 months

1
0
0 0

Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"

by raghu.ncstate＠icloud.com

>> Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. [RK] Agree here. Passing information through the manifest to the SP is orthogonal to the main problem at hand where we are assuming that the size of manifest cannot be > 4K and the entrypoint offset is always at 0x100. -Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, June 22, 2021 7:35 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hi Olivier, >> [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. [VW] You are right - bootloader loads SP.pkg (header+manifest+image) into memory. Can you please help me understand what "SP boot data" contains? For passing the SP manifest pointer to the SP we should ask for ideas from the community. Some ideas to get the discussion started: 1. SPMC creates a mapping for the manifest in the SP's virtual address space. SP issues a SVC call to get the virtual address from the SPMC 2. SPMC creates a mapping for the manifest in the SP's virtual address space and passes the pointer to SP via X0 3. SP manifest contains an entry to publish the virtual address for its manifest. SPMC reads this entry and maps the manifest at that virtual address during boot. >> [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. [VW] Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Tuesday, June 22, 2021 8:17 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, (sorry last message sent too fast) See few comments inline [OD]. Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 17 June 2021 12:33 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. [VW] We don't have a policy for all SPs, yet. At least I don't know of one. But in our experimental setup we plan to work on some assumptions e.g. assume the manifest blob to always be present at a certain address. [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. >> [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. [VW] Can we list down the next steps? Do we agree in principle that sptool needs to be upgraded to handle this use case? We can collaborate on an implementation, once we agree on the direction. [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Thursday, June 17, 2021 8:40 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, Few comments [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 14:37 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. [VW] Thanks for the heads up. >> what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? [VW] We can assume tens of KB. In the worst case, a few hundred KB. The manifest is targeted towards the SP and not meant for Hafnium. Just curious, do you see any pitfalls? [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. >> To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. [VW] Thanks for the links. I will review and leave comments - although we are not looking at introducing yet another script. [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 12:59 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, See inline [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 13:07 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" HI Olivier, >> [OD] Just to be clear, is this about SEL0 partitions using an SEL1 >> shim No, this issue can be seen even without the shim. I don't think the usage of shim or VHE really matters here. [OD] All right. Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. Not an issue as such but just making sure you have the full picture. At some point in time, when Hf VHE changes are merged we can create a specific TF-A test config to cover this case if necessary. Out of curiosity what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? >> [OD] This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. I agree, this approach is good for the short term. But I propose we craft a forward-looking solution. Are you planning on merging the sptool patch[1]? If not, I propose we come up with a way to dynamically update the SP manifest - I understand this involves adding libfdt to update the manifest. [OD] There is no pressing need to merge [1] in the short term so this can wait for a better solution. To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. -Varun [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 11:42 AM To: tf-a(a)lists.trustedfirmware.org; Nicolas Benech <nbenech(a)nvidia.com> Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi, See few comments inline [OD] Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 June 2021 11:41 To: tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms [OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… )? and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. [OD] We had an attempt (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. Cheers. [1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi…> -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

4
11
0 0

Re: [TF-A] A Q about TZ porting guide

by Manish Pandey2

Hi Boaz, It appears that you have included plat/arm files in your platform porting which is causing Arm platform function definition to be included. Along with providing generic implementations Arm also has its own platforms(like any other partner platforms), code under plat/arm is meant only for Arm platforms. Check your make file and make sure that you don't include plat/arm/common/arm_pm.c(to avoid plat_setup_psci_ops) and plat/arm/common/aarch64/arm_helpers.S(for other functions you mentioned) this will avoid multiple definition errors. Hope this helps thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of IS20 Boaz Baron via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 July 2021 09:12 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: Re: [TF-A] A Q about TZ porting guide Also, those functions aren’t defined as WEAK so I encountered the same problem (multiple definitions) plat_crash_console_putc plat_crash_console_flush platform_mem_init From: IS20 Boaz Baron Sent: Thursday, July 29, 2021 10:14 AM To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: RE: [TF-A] A Q about TZ porting guide Thanks Madhukar for your answer, I think I wasn’t so clear. plat_setup_psci_ops is listed as mandatory in the porting guide. I implemented it locally but linkage fails because it is also defined in arm_pm.c. How do you suggest to avoid this multiple definition? Thanks, Boaz. From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Sent: Wednesday, July 28, 2021 10:44 PM To: IS20 Boaz Baron <boaz.baron(a)nuvoton.com<mailto:boaz.baron@nuvoton.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] A Q about TZ porting guide Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don’t think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c…<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] A Q about TZ porting guide 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. ________________________________ 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.

4 years, 3 months

1
0
0 0

Re: [TF-A] A Q about TZ porting guide

by Madhukar Pappireddy

Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don't think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c… Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] A Q about TZ porting guide 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.

4 years, 3 months

2
2
0 0

TF-A Tech Forum Agenda: Thu 29th July 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 29th July 2021 16:00 – 17:00 (BST). Agenda: * Firmware Update Discussions - Led by Manish Badarkhe * A brief overview of firmware update mechanism as per firmware update specification release https://developer.arm.com/documentation/den0118/a/ (Version1.0 BET0). * Discuss TF-A BL2 involvement in the firmware update operation. [Patches for this work are in review: https://review.trustedfirmware.org/q/topic:%22fw-update-2%22+(status:open%2…] * Discuss existing firmware update mechanisms in the partner platforms and if any challenges to adapt to this firmware update specification. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 3 months

1
0
0 0

A Q about TZ porting guide

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.

4 years, 3 months

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.

4 years, 3 months

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

4 years, 3 months

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.

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A