Hi All,
SCR_EL3.EA define whether to route External Abort and SError Interrupt to EL3 or EL2/1. ATF have a compile time flag to HANDLE_EA_EL3_FIRST_NS to program SCR_EL3.EA.
Below text from ATF documentation.
- ``HANDLE_EA_EL3_FIRST_NS``: When set to ``1``, External Aborts and SError
Interrupts, resulting from errors in NS world, will be always trapped in
EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions
will be trapped in the current exception level (or in EL1 if the current
exception level is EL0).
Have question related to forwarding of these errors when External Abort and SError Interrupt are routed to EL3.
In this case will ATF forward Asynchronous SError Interrupt to Linux via RAS?
Thanks
-Bharat
It is observed that functions like macros like NOTICE, WARN and assert are present in the Trusted Firmware-A code. MISRA-C standard treats these as violations. shall we take these as deviation? please suggest.
TFA Guidelines recommends using logging macros. So can we make deviations or need to change the MACRO into function.
Hello,
It is observed that device tree functions are present under lib/libfdt/... in Trusted Firmware-A code, but this device tree are not present in symbol table and also if we remove this device tree functions in code, board was successfully booting. However, while doing Coverity build to fix MISRA-C violations getting violations from this device tree code.
So, is it possible to leave those violations please suggest? And when it will be enabled, please suggest.
Thanks & Regards
Nithin G
Hi Everyone,
I have cancelled the TF-A techforum for latter today as we have no topic scheduled to be discussed.
Calendar cancellations have been sent.
Apologies for the late notification.
Joanna
This event has been canceled with a note:
"Cancelling as we have no topics for today. Apologies for the late
cancellation. Joanna"
TF-A Tech Forum
Thursday Aug 24, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi
I ported TF-A and OPTEE on multi-core SoC, and I checked that xtest passed
on CPU0 without failure. However, I'm failing in secondary CPU boot, and
I'd like to get some help.
I'm using ARMv8, and I'm using spintable as CPU enable method (not using
PSCI FW). TF-A is in EL3.
What I did ...
1. I released secondary CPU reset from bl31_early_platform_setup2() during
primary CPU cold booting
- set secondary CPU's RVBAR to bl31_entrypoint
- release secondary CPU reset
2. I implemeneted plat_secondary_cold_boot_setup(), which is spining until
linux kernel updates cpu-release-addr. Once linux kernel updates
cpu-release-addr, then it changes EL to EL1 and jumps to
secondary_startup() in linux
3. But secondary core goes to panic. It seems to happen when linux invokes
optee_probe()
Should I initialize some contexts (e.g. optee ..)? If so, where should I
implement the corresponding codes? I'm wondering if I'm missing something,
and I'd like to get some advice
Thanks,
--Bin
This event has been canceled with a note:
"Cancelling this weeks TF-A Tech Forum. No topics ready to present and many
people out on vacation."
TF-A Tech Forum
Thursday Aug 10, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
Trusted Firmware-A LTS version 2.8.8 is now available. This release contains the following patches.
* ec3fafa24 fix(cpus): workaround for Neoverse V2 erratum 2801372
The readthedocs update can be found at https://trustedfirmware-a.readthedocs.io/en/lts-v2.8/change-log.html.
Thanks.
Hi Boyan,
Some questions about erratum in TF-A:
1 Why workaround's flag is 0? In my mind, all flag should be 1 because there is func to check cpu revisions,
such as check_errata_2326639.
43438ad1a patch:
+ERRATA_N2_2326639 ?=0
2 After e444763d6(shorten errata flag defines) patch, introduce CPU_FLAG_LIST,
Is the workaround's flag change to 1?
e444763d6 patch:
-ERRATA_N2_2326639 ?=0
+CPU_FLAG_LIST += ERRATA_N2_2326639
Regards,
Ming
Hi All,
I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum
will be hosting a presentation on OpenCI and MISRA presented by Paul
Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being
enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists
since users in both domains may be interested in the session.
Meeting time and dial up info can be found in the TF community calendar
located here: https://www.trustedfirmware.org/meetings/
Best Regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
Typically, BL31 runs in SRAM which tends to be limited. As we add
support for newer architectural features e.g. CCA, general features
and standards, the size of BL31 image will grow and become harder to
fit in most SRAMs.
This email is to share ideas on how to address this problem.
A simple approach will be to identify parts of NOBITS ELF sections of
BL31 which can be moved out to DRAM. Since NOBITS sections aren't part
of the file image, loading and authentication code doesn't have to
change. The challenge will be to come up with some criteria to help
decide what kind of buffers can be kept in DRAM vs SRAM.
Other ideas are also welcome. Please share your thoughts.
Thanks,
Okash
Hi,
We have two topics for the upcoming TF-A Tech Forum on Jul, 13th:
Certificate signer-id retrieval - Manish Badarkhe
* Quick recap
* Authentication Mechanism
* Role of public key
* What is signer ID and its usage?
* Design of signer ID retrieval for attestation
Updates to EL3 vector entry path to cater for async EA(SError) exceptions - Manish Pandey
*
Description of error synchronization during EL3 entry.
* Go through the implementation of handling of these errors in EL3 for Firmware First Handling (FFH) scenarios.
* Reflecting it back in Kernel First Handling (KFH) scenario.
* Description of the test scenarios introduced.
Regards,
Olivier.
________________________________
From: Trusted Firmware Public Meetings
Sent: 14 June 2020 19:21
To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <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: 13 July 2023 17:00-18:00.
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>.
Hi Manish,
I'll answer on behalf of Benjamin and Sieu because I think they are offline now.
I reached out to these guys privately this morning and they said they will post patches to fix these defects.
Cheers,
Sandrine
Hi All,
It has happened in the past that developers have posted patches for review, but have been unable to respond to the comments on those patches for a long time and hence, maintainers pitched in and abandoned the patches in such cases.
I created a patch [1] to make this official because the coding-review guidelines didn't mention it today. I would appreciate your help in reviewing this patch. Please let us know if you disagree about this approach. If you'd like, we can discuss this upcoming tech-forum.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21848
Thanks,
Manish Badarkhe
This event has been canceled with a note:
"No topic this week. Cancelling. Please, if anybody has topics to present
in other future TF-A Techforums please do reach out to me."
TF-A Tech Forum
Thursday Jun 29, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
FYI to all TF dev teams leveraging Open CI.
Best regards,
Don
---------- Forwarded message ---------
From: Glen Valante via Tf-openci-triage <
tf-openci-triage(a)lists.trustedfirmware.org>
Date: Fri, 23 Jun 2023 at 08:41
Subject: [Tf-openci-triage] FYI; Cambridge Lab Down
To: tf-openci-triage(a)lists.trustedfirmware.org <
tf-openci-triage(a)lists.trustedfirmware.org>
Hello All;
FYI; the Cambridge lab took a serious power hit and is down. They are
scrambling to get things back up, but it may take all weekend.
Expect LAVA failures and other strange results.
Thanks;
-g
--
[image: Linaro] <http://www.linaro.org>
Glen Valante | *Director Program & Project Management*
T: +1.508.517.3461 <1617-320-5000>
glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante>
--
Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org
To unsubscribe send an email to
tf-openci-triage-leave(a)lists.trustedfirmware.org
This event has been updated with a note:
"Session for 27th July 2023."
Changed: description
TF-A Tech Forum
Thursday Jul 27, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Topic:MISRA testing in the OpenCI with BUGSENG's ECLAIR Software
Verification PlatformPresenters:Roberto Bagnara (BUGSENG) and Paul
Sokolovskyy (Linaro)Summary:Overview of MISRA C, BUGSENG's ECLAIR Software
Verification Platformand the challenges and solutions for its deployment in
the OpenCIContinuous Integration System for the TF-A and TF-M
TrustedFirmwareOpensource community projects.We run an open technical forum
call for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
lavinia.battaglia(a)bugseng.com
paul.sokolovsky(a)linaro.org
roberto.bagnara(a)bugseng.com
valentina.loggini(a)bugseng.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled.
TF-A Tech Forum
Thursday Jun 15, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi Varun,
* for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
Can you please have a look at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047 ?
and https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047/6/docs…
The model, by the FF-A specification, is to permit G0 interrupts to trap to EL3 when NWd runs.
A G0 interrupt is routed to a SP through the SPMD/SPMC by the use of EL3-SP direct messages:
https://review.trustedfirmware.org/q/topic:%22el3_direct_msg%22+(status:ope…
When SEL1/0 runs, G0 interrupts are first trapped to SEL2 and forwarded to EL3 by the FFA_EL3_INTR_HANDLE ABI.
I appreciate the legacy capability to let G0 interrupts trap to EL3 while SWd runs is not possible/recommended with this design.
This might indeed break earlier implementations; would it make sense aligning SW stacks to the latest of the FF-A spec recommendations?
I let Raghu chime in if need be.
Regards,
Olivier.
________________________________
From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 06 June 2023 13:12
To: TF-A Mailing List <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] EHF and SPMD G0 interrupt handling issues
Hi,
We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF.
I have found the following issues with the implementation.
1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3.
2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality.
3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler.
IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround.
Thoughts?
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.
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 5 of 5 defect(s)
** CID 385350: Control flow issues (DEADCODE)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
________________________________________________________________________________________________________
*** CID 385350: Control flow issues (DEADCODE)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
13
14 #include <plat/common/platform.h>
15 #include <platform_def.h>
16
17 int arm_validate_ns_entrypoint(uintptr_t entrypoint)
18 {
>>> CID 385350: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "-1" inside this statement: "return (entrypoint >= 42947...".
19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0;
20 }
21
22 /* Private event mappings */
23 static sdei_ev_map_t zynqmp_sdei_private[] = {
24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE),
** CID 385349: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize()
________________________________________________________________________________________________________
*** CID 385349: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1409 in intel_fcs_ecdsa_hash_sign_finalize()
1403
1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr,
1405 src_size);
1406
1407 i += src_size / MBOX_WORD_BYTE;
1408
>>> CID 385349: (OVERRUN)
>>> Overrunning array "payload" of 17 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ,
1410 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
1411 &resp_len);
1412
1413 memset((void *) &fcs_ecdsa_hash_sign_param,
1414 0, sizeof(fcs_crypto_service_data));
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize()
1398
1399 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
1400 FCS_ECDSA_HASH_SIGN_CMD_MAX_WORD_SIZE) {
1401 return INTEL_SIP_SMC_STATUS_REJECTED;
1402 }
1403
>>> CID 385349: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 68 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr,
1405 src_size);
1406
1407 i += src_size / MBOX_WORD_BYTE;
1408
1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ,
** CID 385348: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize()
________________________________________________________________________________________________________
*** CID 385348: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize()
2138
2139 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
2140 FCS_ECDH_REQUEST_CMD_MAX_WORD_SIZE) {
2141 return INTEL_SIP_SMC_STATUS_REJECTED;
2142 }
2143
>>> CID 385348: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 116 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size);
2145 i += src_size / MBOX_WORD_BYTE;
2146
2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST,
2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
2149 &resp_len);
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2147 in intel_fcs_ecdh_request_finalize()
2141 return INTEL_SIP_SMC_STATUS_REJECTED;
2142 }
2143
2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size);
2145 i += src_size / MBOX_WORD_BYTE;
2146
>>> CID 385348: (OVERRUN)
>>> Overrunning array "payload" of 29 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST,
2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
2149 &resp_len);
2150
2151 memset((void *)&fcs_ecdh_request_param, 0,
2152 sizeof(fcs_crypto_service_data));
** CID 385347: Control flow issues (NO_EFFECT)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
________________________________________________________________________________________________________
*** CID 385347: Control flow issues (NO_EFFECT)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
13
14 #include <plat/common/platform.h>
15 #include <platform_def.h>
16
17 int arm_validate_ns_entrypoint(uintptr_t entrypoint)
18 {
>>> CID 385347: Control flow issues (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. "entrypoint < 0UL".
19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0;
20 }
21
22 /* Private event mappings */
23 static sdei_ev_map_t zynqmp_sdei_private[] = {
24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE),
** CID 385346: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize()
________________________________________________________________________________________________________
*** CID 385346: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1510 in intel_fcs_ecdsa_hash_sig_verify_finalize()
1504
1505 memcpy((uint8_t *) &payload[i],
1506 (uint8_t *) hash_sig_pubkey_addr, src_size);
1507
1508 i += (src_size / MBOX_WORD_BYTE);
1509
>>> CID 385346: (OVERRUN)
>>> Overrunning array "payload" of 52 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY,
1511 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
1512 &resp_len);
1513
1514 memset((void *)&fcs_ecdsa_hash_sig_verify_param,
1515 0, sizeof(fcs_crypto_service_data));
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize()
1499
1500 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
1501 FCS_ECDSA_HASH_SIG_VERIFY_CMD_MAX_WORD_SIZE) {
1502 return INTEL_SIP_SMC_STATUS_REJECTED;
1503 }
1504
>>> CID 385346: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 208 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
1505 memcpy((uint8_t *) &payload[i],
1506 (uint8_t *) hash_sig_pubkey_addr, src_size);
1507
1508 i += (src_size / MBOX_WORD_BYTE);
1509
1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY,
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF.
I have found the following issues with the implementation.
1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3.
2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality.
3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler.
IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround.
Thoughts?
I am working on qemu_sbsa platform. We are now adding a way to share
data from QEMU via TF-A to EDK2. Standard Arm way - using Secure Monitor
Calls.
I checked how other platforms do it and wrote a patch [1]. It got
reviews, went through CI and all is fine except one thing:
New source files have been identified in your patch..
plat/qemu/qemu_sbsa/sbsa_sip_svc.c
1. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20871
I have read TF-A documentation linked to CI report. This new file is
covered already by PLAT=qemu_sbsa build because it is not optional. How
to make CI pass?
Same problem is with second patch [2] where I added another new source file.
2. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20953
This event has been updated with a note:
"Update for Techforum tomorrow...."
Changed: description
TF-A Tech Forum
Thursday Jun 1, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Topic: SVE Enablement in RMM for Realms. Presenter: Arunachalam
GanapathyOverview: This discussion will cover the design and implementation
details on how SVE and FP/AdvSIMD state of Non secure world and Realms are
managed by RMM.=====================We run an open technical forum call for
anyone to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
tf-rmm(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.9 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium and TF-A OpenCI Scripts/Jobs 2.9 releases involving the tagging of multiple repositories. Aligned but not yet part of the release is Trusted Firmware-A Realm Management Monitor v0.3.0.
These went live on 23rd May 2023.
I would like to thank all of the contributors for their excellent work and achievements since the last release.
Thanks Joanna
Notable Features of the Version 2.9 Release are as follows:
TF-A/EL3 Root World
* New Features:
* Support for PSCI OS initiated mode
* Architecture feature support for FEAT_TCR2, FEAT_GCS, FEAT_HCX, FEAT_SME2, FEAT_PIE/POR, FEAT_MPAM.
* System registers access trap handler
* Introduction to dynamic detection of features
* Refactoring:
* Context management
* RAS extension exception handling and crash reporting.
* Distinguish between BL2 as TF-A entry point or BL2 running at EL3 exception level.
* General Support
* CPU Support for Chaberton and Blackhawk for TC2023
* Eighteen (18) Errata Mitigations for Cortex X2/X3/A710/A510/A78/A78C and Neoverse N2/V1 family CPU’S
* Errata Management Firmware Interface implementation supported for version 1.0 of the public specification
TF-A Boot BL1/BL2
* New Feature/Support
* Support for Trusted Boot rooted into RSS RoT on TC2022 platform.
* Support for PSA attestation scheme with Measured Boot rooted into RSS on TC2022 platform
* Migration to mbedTLS 3.x as the default cryptography library retaining backwards compatibility with mbedTLS 2.x
* Improvements and hardening of Arm CCA boot and attestation support.
* Hardening efforts in the X.509 certificate parser, including a security fix (TFV-10 CVE-2022-47630)
Hafnium/SEL2 SPM
* FF-A v1.2 ALP0 Specification Early Adoption Support
* Implemented ppartition info get ABI using GP registers.
* Group0 secure interrupt handling delegation.
* Improved console log ABI.
* FF-A v1.1 REL0 Specification Support
* Interrupt handling (S-EL0 partition signalling, added action to Other-S-Int, allow a physical interrupt to be routed to a specified PE).
* Memory sharing (structures updates supporting FF-A backwards compatibility, share/lend/donate memory to multiple borrowers, normal/secure fragmented memory sharing).
* Power management (events relayed to the SPMC and removed limitations).
* Indirect messaging (buffer synchronization and ownership transfer rules).
* General Support
* SPMC manifest to declare non-secure and secure system memory address ranges.
* Hardened SP manifest memory regions boot time validation.
* CI migration to LLVM/clang 15.0.6
* Removal of non-VHE build and test configurations.
* Added EL3 SPMC test configurations using the Hafnium's CI infrastructure.
TF-A Tests
* New Test Support
* Errata Management Firmware Interface testing
* FF-A v1.1 feature testing
* Realm Management Extension feature testing
* New Architecture Specific feature testing related to v8.8
* 1 new platform port (RD-N2-Cfg3)
TF-RMM/REL2
* New Feature/Support
* Added support to create Realms which can make use of SVE, if present in hardware.
* Refactor and improved the Stage 1 translation table library lib/xlat API to better fit RMM usage.
* Add PMU support for Realms as described by RMM v1.0 Beta0 specification.
* Support getting DRAM info from the Boot manifest dynamically at runtime.
* RMM can now support the 2nd DDR bank on FVP
* Define a unit test framework using CppUTest for RMM.
* Added unit tests for granule, slot-buffer and Stage 1 translation table lib xlat.
* Improvements to fake-host and unit tests framework.
* Build improvements in RMM
Platform Support
* 1 new platform added, the Allwinner T507 SoC
* 26 platforms updated from 14 providers
* 17 different driver updates
OpenCI
* First release done solely relying on Trustedfirmware.org OpenCI
Patch Statistics Across all Repositories
* 1403 Patches merged since v2.8 November 2022 release
Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release.
TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and changelog [10].
[1] https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html#id1
[2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…
[3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.9/change-log.html#vers…
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9
[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.9
[6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.9
[7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.9
[8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.9
[9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.3.0
[10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.3.0/about/change-log.html#v0-3-0
Hi,
I am pleased to announce that Yann Gautier has now become one of the
maintainers for TF-A. This decision is based on Yann's continued efforts
and involvement in the project over the years.
A patch is under review to reflect this in TF-A documentation:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21060
Best regards,
Sandrine (on behalf of all TF-A maintainers)
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Jun 1, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Provisional topic: SVE enablement for Realms. More details on this nearer
the time....=====================We run an open technical forum call for
anyone to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Apologies for late notice but the TF-A TechForum is cancelled today.
We were hoping a topic would be ready however that is not the case.
I try to send notifications a day before but over looked that last night.
I will be provisionally updating the session on 2nd June with a topic.
Thanks
Joanna
This event has been canceled.
TF-A Tech Forum
Thursday May 18, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.9 release during the middle of May 2023 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.8 release. As part of this, a release candidate tag is targeted to be created and release activities commence from 10th May 2023 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.9 release are submitted in good time to be complete by 9th May 2023.
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 Job. In addition a TF-RMM repository release will be made that is compatible with v2.9.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start normally completing within 7-10 working days.
Regards
Joanna Farley
Hi,
I am currently doing research to implement the Transfer List to comply with
Arm's firmware handoff spec (
https://github.com/FirmwareHandoff/firmware_handoff) in order to have a
standardized handoff approach between different firmware stages during boot.
The idea is to create a Transfer List in BL2 and cache it into a
pre-allocated memory in SRAM that can be shared between BL2 and BL3x.
A prototype currently available is creating APIs under qemu platform code
to retrieve the pre-defined memory address (The shared memory region is
defined in platform_def.h).
But I think we need to define a common API for this purpose to support all
platforms.
Please share your views or any suggestions.
Thanks.
Regards,
Raymond
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 384887: Uninitialized variables (UNINIT)
/mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name()
________________________________________________________________________________________________________
*** CID 384887: Uninitialized variables (UNINIT)
/mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name()
1390 if (ret != 0) {
1391 return ret;
1392 }
1393
1394 memset(san, 0, sizeof(mbedtls_x509_subject_alternative_name));
1395 san->type = MBEDTLS_X509_SAN_OTHER_NAME;
>>> CID 384887: Uninitialized variables (UNINIT)
>>> Using uninitialized value "other_name". Field "other_name.type_id" is uninitialized when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.]
1396 memcpy(&san->san.other_name,
1397 &other_name, sizeof(other_name));
1398
1399 }
1400 break;
1401 /*
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback.
This activity followed the request of some members of the Arm ecosystem [2].
The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot.
The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden.
The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data.
New types are meant to be added, following the needs and use-cases of the different communities.
Thus, these communities should be empowered to request new types!
To enable community contributions, the specification must be hosted in a location that is friendly to change requests.
We propose to host the spec in trustedfirmware.org (tf.org).
Tf.org hosts several open-source projects and already has an open governance model.
TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date.
Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.).
We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed!
If anyone has objections, we are happy to consider alternatives and associated trade-offs.
Regards
[1] https://developer.arm.com/documentation/den0135/latest
[2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>
This event has been canceled.
TF-A Tech Forum
Thursday May 4, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
We have a use case where we want to deny the CPU power off from a certain PE. The current lib/psci does not provide a way for a platform to do this. We have support to return an error from svc_off, but this does not cover the scenario where svc_off is NULL.
There are multiple ways of handling this scenario.
1. Introduce a new platform function to check if CPU_OFF is allowed on the core
2. Return an error code from the pwr_domain_off() handler and unwind the CPU_OFF request
3. Something else.
Any suggestions?
-Varun
This event has been canceled with a note:
"The original topic for this TechForum will be held on a future date. No
alternative topic has been identified for this session so cancelling."
TF-A Tech Forum
Thursday Apr 20, 2023 ⋅ 4pm – 5pm
United Kingdom Time
This session will no longer take place on this date. It will be
rescheduled.This slot is now free for another session although nothing has
yet been identified.======================================Reserving for a
discussion on Signer-id Extraction Design for Manish Badarkhe. More details
of this session will be sent closer to the session date.-----------------We
run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to colleagues.
Invites are via the TF-A mailing list and also published on the Trusted
Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
don.harbin(a)linaro.org
moritzf(a)google.com
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
This is a courtesy notification that we plan to deprecate Arm
CryptoCell-712 and CryptoCell-713 drivers in TF-A release v2.9, with the
goal to remove their source code from the tree in the following TF-A
release after that.
This won't affect any upstream platforms beyond Arm Ltd platforms (under
plat/arm/ folder).
If you have any concerns with this, please raise them by Monday, April 24th.
Best regards,
Sandrine
Hi, I'm using TF-A 2.8 on mt7986 board, enable TRUSTED_BOARD_BOOT using mbedtls-3.4.0,
TF-A BL2 hanged when loading BL31, it seems that BL2 failed to get correct oid in function get_ext(drivers/auth/mbedtls/mbedtls_x509_parser.c) after calling mbedtls_oid_get_numeric_string
mbedtls_oid_get_numeric_string in 3.4.0 uses %c to print part of oid,
(https://github.com/Mbed-TLS/mbedtls/blob/v3.4.0/library/oid.c#L864)
but seems that ATF libc's snprintf doesn't support %c format, which causes mbedtls_oid_get_numeric_string to return incorrect oid
oid_str dump in get_ext
oid_str=%c.49.6.1.4.1.4128.2100.1 (mbedtls_oid_get_numeric_string)
oid_str=1.3.6.1.4.1.4128.2100.1 (TRUSTED_FW_NVCOUNTER_OID)
I try to change snprintf format %c to %u in mbedtls_oid_get_numeric_string, TF-A boots successfully
Thanks
Hi,
Concerning the following Fast Model Component:
https://developer.arm.com/documentation/100964/1121/Fast-Models-components/…
This component is already publicly documented although it is not integrated yet into the AEM FVP.
The main usage is to identify software mis-programming, where the same Physical address is accessed through more than one Physical Address Space (PAS). As such, it is intended as a development / debugging tool only. If such a mis-programming scenario happened then the memory page corresponding to the accessed physical address would get corrupted.
Notice memory encryption is not yet supported in TF-A's SW stacks. You won't find a reference for this feature in TF-A / TF-a-tests just now.
Best regards,
Sandrine
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Apr 20, 2023 ⋅ 4pm – 5pm
United Kingdom Time
This session will no longer take place on this date. It will be
rescheduled.This slot is now free for another session although nothing has
yet been identified.======================================Reserving for a
discussion on Signer-id Extraction Design for Manish Badarkhe. More details
of this session will be sent closer to the session date.-----------------We
run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to colleagues.
Invites are via the TF-A mailing list and also published on the Trusted
Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
don.harbin(a)linaro.org
moritzf(a)google.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons,
I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment.
I use CROSS_COMPILE=aarch64-gcc-7.5.0.
It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries,
and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A.
I wonder is TF-A going to support MBEDTLS_AESCE_C option?
Thanks
Hi all,
I want to test the memory encryption functions in Arm CCA. Currently,
I find that Arm FVP supports a PVMemoryProtectionEngine. Thus, can I
use this engine in current TF-A or TF-A-Tests? If yes, how to use this
engine?
Sincerely,
WANG Chenxu
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Apr 20, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Reserving for a discussion on Signer-id Extraction Design for
Manish Badarkhe. More details of this session will be sent closer to the
session date.-----------------We run an open technical forum call for
anyone to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
I have talked to a couple of people to figure out what TF-A project is
using for code documentation. Because I see at least in our platform
that our documentation is somewhere between doxygen and kernel-doc but
actually with a lot of mismatches.
Sanbrine mentioned sending an email to the mailing list to start to
have discussion about it.
That's why I want to know the official code documentation format and
how we should be checking that everything matches to make sure that
documentation is not out of sync from code itself.
When this is clear I will ask my team to fix all these issues.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Hello all,
We are sending this note to notify you of one of the breaking changes related to the enablement of FEAT_SVE in TF-A. This mainly impacts platforms which are configurable (FVP, QEMU, Total Compute).
FEAT_SVE has now been moved under the Feature detection mechanism wherein a CPU feature macro can have 3 possible states
* 0: FEAT_STATE_DISABLED
* 1: FEAT_STATE_ALWAYS ( Always enabled, no runtime check)
* 2: FEAT_STATE_CHECK (Dynamically check based on ID registers, done each time when feature registers are being accessed)
For platforms which have a single configuration, it's better to choose either disabled or enabled (as it is a bit faster as there is no dynamic check).
For platforms which can have different HW configurations, it makes sense to put them under FEAT_STATE_CHECK(=2), so that they will boot with any configuration of HW.
Keeping this in mind, all configurable platforms (FVP, QEMU, TC) have been modified to adopt dynamic detection(FEAT_STATE_CHECK) for FEAT_SVE. [1]
SVE Patch Reference:
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20306
Best regards,
Jayanth
Hello Kever,
on a rk3399, booting current U-Boot SPL with mainline TF-A leads to
missing DMA (and no sound) on Linux.
However, when using rockchip its so called mini-loader
(rk3399_miniloader_v1.26.bin) and their BL31 (rk3399_bl31_v1.35.elf) to
boot, DMA works perfectly fine.
Tested on a custom rk3399 board and on ROCK Pi4.
Attached to this mail are two boot logs with some debug prints:
- good_amba_log.txt (DMA works)
- no_amba_log.txt (no DMA device)
The main difference I can spot between the two logs is that on Linux
(drivers/amba/bus.c) AMBA_CID (0xb105f00d) cannot be found. Instead,
only some CORESIGHT_CIDs (presumably for debugging) and four 0x00000000
CIDs are detected.
As a result, the "PL330 DMAC-241330" driver does not load. My theory is
that DMA needs to be allowed somewhere in the undocumented syscon-
registers, similar to what U-Boot is already doing for eMMC in
arch_cpu_init() (arch/arm/mach-rockchip/rk3399/rk3399.c).
Any ideas?
Or maybe I'm just missing some configuration?
Since multiple software projects are involved (TF-A, OP-TEE, U-Boot,
Linux), I Cc'ed a bit.
Thanks
-- Christoph
This event has been canceled with a note:
"No topics this week so cancelling."
TF-A Tech Forum
Thursday Apr 6, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi Folks,
I’ve just updated the Techforum session information (Slides and Recording) from the RAS Handing session last week on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ which will be deployed soon once the patch is approved.
The next TF-A Tech forum is due on Thursday 6th April at 4pm BST.
At this time I don’t have any topics for that session. If anybody in the community has anything they would like to present please do reach out to me.
Thanks
Joanna
Hi,
according to the current erratum document for the ARM Cortex-A78AE [0], the workaround for erratum 1941500 says:
"This erratum can be avoided by setting CPUECTLR_EL1[8] to 1."
However, the current code on branch "master" (git hash 5906d97a832b6f6 ) at
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a…
executes a "bic" instruction with an immediate, which is a synthetic instruction to clear the bit, instead of setting it. Moreover, the comment above says "Set bit 8 in ECTLR_EL1", which is inconsistent to the code.
The equivalent workaround for the Cortex-A78 non-AE (erratum 1941498) uses the correct "orr" (bitwise-or) instruction to set the bit:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a…
Please confirm if this is an error.
Thank you.
Best Regards,
Matthias
[0] "Arm Cortex-A78AE (MP105) Software Developer Errata Notice", Document version: v14.0, Document ID: SDEN-1707912,
https://developer.arm.com/documentation/SDEN1707912/latest
Hi all,
I try to enable the smmu of Juno R2 development board but face two
great challenges. I am working on them and I still need some hints.
Here are my problems:
1. By reading the SMMUv1 manuals I find that several registers are
related to secure state (e.g., SMMU_sCR0). But in my TF-A and the
latest version I can only find the SMMUv3 configurations, not
SMMUv1/2. Thus, how to config these registers? Any reference?
2. For the non-secure GPU SMMU regs, I try to map and read them based
on the Juno R2 manual. I know the GPU SMMU is a MMU-400, and its mmio
is in 0x2b40_0000 - 0x2b40_ffff. Then in EL1 I first do
ioremap(0x2b400000,0x10000) and then ioread32(). However I get the
SError as "Bad mode in Error handler detected on CPU1, code
0xbf000002". I also try to do it in EL2 (with a hvc call and reading
in the handler), but cannot get any valid number and still get SError
when exiting EL2. But when I access the other smmus (e.g., a PCIe
SMMU, in 0x2b50_0000), it works fine. Thus, is there something to
prevent the Non-secure World from accessing the GPU SMMU MMIO?
My source codes are downloaded from the arm-reference-platforms, in
which Linux is v4.14.59 and TF-A is v2.1.
Can someone help me?
Sincerely,
WANG Chenxu
This event has been updated with a note:
"Updated agenda"
Changed: description
TF-A Tech Forum
Thursday Mar 23, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Discussion Topic: RAS Refactoring Presented by: Manish Pandey and Soby
MathewTopics to be discussed 1. Introduction to philosophies of handling
RAS errors(FFH/KFH) 2. Discussing exceptions caused by synchronization
barriers at execption boundries 3. Refactoring and enhancements in
TF-A(along with various build macros) 4. Tests introduced 5. Future
work----------------We run an open technical forum call for anyone to
participate and it is not restricted to Trusted Firmware project members.
It will operate under the guidance of the TF TSC. Feel free to forward this
invite to colleagues. Invites are via the TF-A mailing list and also
published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
don.harbin(a)linaro.org
bpeckham(a)google.com
moritzf(a)google.com
kh3195(a)columbia.edu
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
I have already created patch in tf-a for review, added plat Nuvoton
npcm845x, gerrit topic No. 20088.
How should I upload a scripts patch to support new added platform?
In documentation I didn't found how exactly should I send a scripts patch.
Thank you in advance.
Margarita Glushkin
Hi,
I would like to get some feedback on the gicv3 workaround [1] for NVIDIA erratum T241-FABRIC-4. The commit description describes the erratum and the fix in detail.
The patch is only to start a dialogue and gather feedback on the way forward.
Please advise.
Thanks.
[1] fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4 (I04e33ba6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19969>
Hi, experts,
I have another two other questions about this issue.
(1) What should I do if the current optee to load already exists or I want to update optee?
The most straightforward way I could think of is to reclaim the memory currently used by optee, then reload the optee image and initialize it.
(2) optee may use multiple cores. When and how to process the initialization of multiple cores?
Do you have any solutions or ideas?
Regards,
Yuye.
------------------------------------------------------------------
发件人:梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
发送时间:2023年3月11日(星期六) 21:44
收件人:Jens Wiklander <jens.wiklander(a)linaro.org>; tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
抄 送:Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
主 题:Re: Post-boot loading of OP-TEE
Hi, experts,
If I want to apply the code to the S-EL2 framework (Hafnium as SPMC),
What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save?
I'm not clear about the details of the process, can you give me some help?
Regards,
Yuye.
------------------------------------------------------------------
发件人:Jens Wiklander <jens.wiklander(a)linaro.org>
发送时间:2023年1月9日(星期一) 15:39
收件人:tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
抄 送:Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
主 题:Post-boot loading of OP-TEE
Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread [2] about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
to BL31
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review [1], but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in [3]. This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 >
[2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… >
[3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 >
Thanks,
Jens
Hi, experts,
If I want to apply the code to the S-EL2 framework (Hafnium as SPMC),
What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save?
I'm not clear about the details of the process, can you give me some help?
Regards,
Yuye.
------------------------------------------------------------------
发件人:Jens Wiklander <jens.wiklander(a)linaro.org>
发送时间:2023年1月9日(星期一) 15:39
收件人:tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
抄 送:Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
主 题:Post-boot loading of OP-TEE
Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread [2] about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
to BL31
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review [1], but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in [3]. This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 >
[2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… >
[3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 >
Thanks,
Jens
Hi all,
I presented the Errata ABI design and Implementation in this week's tech forum; the patches are available for review, and any feedback, discussions are welcome.
Link to the patch : feat(errata_abi): errata management firmware interface (I70f0e256) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19835>
The team would like to merge this feature by the end of March, kindly help review and provide feedback.
Thanks
-Sona
Hi all,
As presented on this week's tech forum, I have recently been working on
a framework to improve errata implementations, consolidate the disparate
requirements around them, and make errata information available at
runtime. This is related, but separate to the errata ABI which is being
worked on by Sona. Patches are available for review [1] and feedback is
welcome.
This email is to host discussion around the proposal, especially things
that came up during the tech forum. The team would like to merge this
sometime in April, but the sooner it is accepted, the sooner we can
start (and complete!) the migration.
[1]:
https://review.trustedfirmware.org/q/topic:%22bk%252Ferrata_refactor%22+
Hi James & TF-A guys,
When hest acpi table configure Hardware Error Notification type as
Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with
TF-A by SDEI mechanism. On the firmware first system, kernel was notified by
TF-A sdei call.
The calling flow like as below when fatal RAS error happens:
TF-A notify kernel flow:
sdei_dispatch_event()
ehf_activate_priority()
call sdei callback // callback registered by kerenl
ehf_deactivate_priority()
Kernel sdei callback:
sdei_asm_handler()
__sdei_handler()
_sdei_handler()
sdei_event_handler()
ghes_sdei_critical_callback()
ghes_in_nmi_queue_one_entry()
/* if RAS error is fatal */
__ghes_panic()
panic()
If fatal RAS error occured, panic was called in sdei_asm_handle()
without ehf_deactivate_priority executed, which lead interrupt masked.
If interrupt masked, system would be halted in kdump flow like this:
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq
arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting...
So interrupt should be restored before panic otherwise kdump will hang.
In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME)
call should be called before panic for a completed run of ehf_deactivate_priority().
The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80).
The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called.
This will bring about two issue:
1 Kdump will hang for firmware reporting fatal RAS event by SDEI;
(as explain above)
2 For NMI scene,TF-A enable a secure timer, the PPI 29 will trigger periodically.
Kernel register a callback for hard lockup. The below code will not be
called when panic in kernel callback:
TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler():
/*
* We reach here when client completes the event.
*
* If the cause of dispatch originally interrupted the Secure world,
* resume Secure.
*
* No need to save the Non-secure context ahead of a world switch: the
* Non-secure context was fully saved before dispatch, and has been
* returned to its pre-dispatch state.
*/
if (sec_state == SECURE)
restore_and_resume_secure_context();
/*
* The event was dispatched after receiving SDEI interrupt. With
* the event handling completed, EOI the corresponding
* interrupt.
*/
if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) {
ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num);
panic();
}
plat_ic_end_of_interrupt(intr_raw);
How to fix above issues?
I think the root cause is that kernel broken the SDEI dispatch flow, so kernel
should modify to fix these issues.
Thanks,
Ming
Hello,
I am working on a board based on NXP LS1043 processor (arm64) with TPM2 on SPI interface.
I have the following boot sequence : TF-A + UBOOT + YOCTO.
I have a look on the code where the TF-A MEASURE_BOOT was implemented for the fvp arm platform using OPTEE fTPM.
As far as I understood, the event log is implemented based on the TCG2 EFI PROTOCOL from commit :
commit 3ee148d6439b69d326f8e6d2a4ce822604e0e64c
Merge: 43f7d8879 4a135bc33
Author: joanna.farley <joanna.farley(a)arm.com>
Date: Wed Jul 22 16:35:11 2020 +0000
Nevertheless, I am surprised because I did not find any TPM2 driver in the current TF-A code.
I would like to know :
1. How to port what was done for the fvp platform to my platform ?
2. What is code hashed in the TFA to create the event log ?
3. Why are there no TPM2 routine in the TF-A to expend PCR ?
Thanks in advance for your help
Benoit
Hi,
The PSCI specification defines two different power state coordination modes
for CPU_SUSPEND that can be used to put a core or a group of cores into a
low-power state. These modes are the platform-coordinated mode (default)
and the OS-initiated mode (optional). OS-initiated mode is currently not
supported by TF-A, while both modes are supported by the Linux Kernel.
Requesting reviews for the patches [1] adding support for OS-initiated mode
in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
comments are much appreciated.
Thanks in advance!
Wing
[1] https://review.trustedfirmware.org/q/topic:psci-osi
Hello,
I'm a noob here, and I need help. I've just built flash-image.bin for
my MACCHIATObin Single Shot as follows, but it fails to boot - as
follows further below:
- git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
- Clone the binaries-marvell and mv-ddr-marvell Git repos alongside the
trusted-firmware-a, and check out revisions as recommeded in TF-A build
instructions for Armada80x0
(https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/buil…).
- export
CROSS_COMPILE=/my/path/to/arm-gnu-toolchain/11.3.rel1-x86_64-aarch64-none-elf/bin/aarch64-none-elf-
- Build u-boot.bin:
- git clone https://source.denx.de/u-boot/u-boot.git alongside the
binaries-marvell and mv-ddr-marvell repos.
- cd u-boot
- git checkout v2023.01 - the latest release.
- make mvebu_mcbin-88f8040_defconfig
- Change CONFIG_DEFAULT_DEVICE_TREE to "armada-8040-mcbin-singleshot"
(inspired by this SolidRun doc:
https://github.com/SolidRun/documentation/blob/bsp/8040/u-boot.md).
- Add arch/arm/dts/armada-8040-mcbin-singleshot.dts. Can be obtained
e.g. from the latest Marvell kernel sources
(https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/).
- make
- Built fine.
- Build TF-A:
- cd ../trusted-firmware-a/
- git checkout v2.8.0 - the latest release, as per changelog
(https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html).
- make PLAT=a80x0_mcbin MV_DDR_PATH=../mv-ddr-marvell
SCP_BL2=../binaries-marvell/mrvl_scp_bl2.img BL33=../u-boot/u-boot.bin
mrvl_flash
- Built fine.
Then I flashed the flash-image.bin onto my SD card: dd
if=trusted-firmware-a/build/a80x0_mcbin/release/flash-image.bin
of=/dev/mmcblk0 seek=4096 conv=fdatasync,notrunc (as per
https://archlinuxarm.org/platforms/armv8/marvell/macchiatobin).
It boots, but complains about a missing serial driver and resets in a loop:
---
BootROM - 2.03
Starting CP-0 IOROM 1.07
Booting from SD 0 (0x29)
Found valid image at boot postion 0x002
lNOTICE: Starting binary extension
NOTICE: SVC: DEV ID: 8040, FREQ Mode: 0xd
NOTICE: SVC: AVS work point changed from 0x29 to 0x29
mv_ddr: devel-g541616b (Mar 05 2023 - 14:15:32)
mv_ddr: completed successfully
NOTICE: Cold boot
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.8(release):v2.8
NOTICE: BL1: Built : 14:15:45, Mar 5 2023
NOTICE: BL1: Booting BL2
NOTICE: BL2: v2.8(release):v2.8
NOTICE: BL2: Built : 14:15:48, Mar 5 2023
NOTICE: SCP_BL2 contains 7 concatenated images
NOTICE: Load image to CP1 MG
NOTICE: Loading MG image from address 0x402305c Size 0xe0f0 to MG at
0xf4100000
NOTICE: Load image to CP0 MG
NOTICE: Loading MG image from address 0x403114c Size 0xe0f0 to MG at
0xf2100000
NOTICE: Skipping MSS CP3 related image
NOTICE: Skipping MSS CP2 related image
NOTICE: Load image to CP1 MSS AP0
NOTICE: SECURELY Loading MSS FW from addr. 0x4042c34 Size 0x1cfc to MSS
at 0xf4280000
NOTICE: CP MSS startup is postponed
NOTICE: Done
NOTICE: Load image to CP0 MSS AP0
NOTICE: SECURELY Loading MSS FW from addr. 0x4044930 Size 0x1cfc to MSS
at 0xf2280000
NOTICE: CP MSS startup is postponed
NOTICE: Done
NOTICE: Load image to AP0 MSS
NOTICE: Loading MSS FW from addr. 0x404662c Size 0x5400 to MSS at
0xf0580000
NOTICE: Done
NOTICE: SCP Image doesn't contain PM firmware
NOTICE: BL1: Booting BL31
lNOTICE: Starting CP0 MSS CPU
NOTICE: Starting CP1 MSS CPU
NOTICE: MSS PM is not supported in this build
NOTICE: BL31: v2.8(release):v2.8
NOTICE: BL31: Built : 14:15:55, Mar 5 2023
<debug_uart>
No serial driver found
resetting ...
---
Can anyone advise how to fix this? Is this list even the right place to
ask such questions?
Maciej
--
Maciej Sieczka
http://www.sieczka.org
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 383288: (CHECKED_RETURN)
/mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod()
/mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod()
________________________________________________________________________________________________________
*** CID 383288: (CHECKED_RETURN)
/mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod()
1664 *
1665 * To achieve this, we make a copy of X and we use the table entry in each
1666 * calculation from this point on.
1667 */
1668 const size_t x_index = 0;
1669 mbedtls_mpi_init( &W[x_index] );
>>> CID 383288: (CHECKED_RETURN)
>>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times).
1670 mbedtls_mpi_copy( &W[x_index], X );
1671
1672 j = N->n + 1;
1673 /* All W[i] and X must have at least N->n limbs for the mpi_montmul()
1674 * and mpi_montred() calls later. Here we ensure that W[1] and X are
1675 * large enough, and later we'll grow other W[i] to the same length.
/mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod()
1861 MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &W[x_index], N, &W[x_index] ) );
1862 }
1863
1864 /*
1865 * Load the result in the output variable.
1866 */
>>> CID 383288: (CHECKED_RETURN)
>>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times).
1867 mbedtls_mpi_copy( X, &W[x_index] );
1868
1869 cleanup:
1870
1871 /* The first bit of the sliding window is always 1 and therefore the first
1872 * half of the table was unused. */
** CID 383287: Null pointer dereferences (FORWARD_NULL)
________________________________________________________________________________________________________
*** CID 383287: Null pointer dereferences (FORWARD_NULL)
/mbedtls/library/rsa_alt_helpers.c: 134 in mbedtls_rsa_deduce_primes()
128
129 for( ; attempt < num_primes; ++attempt )
130 {
131 mbedtls_mpi_lset( &K, primes[attempt] );
132
133 /* Check if gcd(K,N) = 1 */
>>> CID 383287: Null pointer dereferences (FORWARD_NULL)
>>> Passing "P" to "mbedtls_mpi_gcd", which dereferences null "P->p".
134 MBEDTLS_MPI_CHK( mbedtls_mpi_gcd( P, &K, N ) );
135 if( mbedtls_mpi_cmp_int( P, 1 ) != 0 )
136 continue;
137
138 /* Go through K^T + 1, K^(2T) + 1, K^(4T) + 1, ...
139 * and check whether they have nontrivial GCD with N. */
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
mmc_enumerate() is the only caller of mmc_send_op_cond().
mmc_enumerate() calls mmc_reset_to_idle() just before calling
mmc_send_op_cond(). No need to do that again in mmc_send_op_cond().
Signed-off-by: Baruch Siach <baruch(a)tkos.co.il>
Change-Id: Ib8c8ed1a559e3fecb315245f91bb3dc1f547d820
---
Sending the patch to the list once again. review.trustedfirmware.org
does not work for me.
https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
---
drivers/mmc/mmc.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 2b727d4e7696..57f47482013a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -452,11 +452,6 @@ static int mmc_send_op_cond(void)
int ret, n;
unsigned int resp_data[4];
- ret = mmc_reset_to_idle();
- if (ret != 0) {
- return ret;
- }
-
for (n = 0; n < SEND_OP_COND_MAX_RETRIES; n++) {
ret = mmc_send_cmd(MMC_CMD(1), OCR_SECTOR_MODE |
OCR_VDD_MIN_2V7 | OCR_VDD_MIN_1V7,
--
2.39.2
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Mar 23, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Rescheduling the 2&4 world RAS architectural changes discussion.More
details nearer the event.----------------We run an open technical forum
call for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Mar 9, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Changing this session for Errata ABI and Errata Framework discussions.A
more detailed agenda will be issued closer to the
event.---------------------We run an open technical forum call for anyone
to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
Michal Simek
don.harbin(a)linaro.org
ulf.hansson(a)linaro.org
moritzf(a)google.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
In ARM TBBR, there is a requirement
“R0100_TBBR_AFM_FLASHING” (The AP firmware must switch to the Non-Trusted world for executing the SoC firmware loader),
But there is no requirement for secure boot as long as I finish chain if ROT verification.
So, can I implement FWU in BL2 which is verified and load from BL1 (ROM)?
For example,
BL1(ROM) -> Load and verify BL2U with new image from SD to secure RAM -> execute BL2U in Secure RAM then write new image to NAND flash
Best regards,
Jun
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Mar 9, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Reserving this session for a TF-A RAS support update in an evolving Arm
architecture.A more detailed agenda will be issued closer to the
event.---------------------We run an open technical forum call for anyone
to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been updated
Changed: location
TF-A Tech Forum
Thursday Feb 23, 2023 ⋅ 8am – 9am
Pacific Time - Los Angeles
Location
US-MTV-1015-1-S-Silicon (2) [GVC, Phone]
https://www.google.com/maps/search/US-MTV-1015-1-S-Silicon+(2)+%5BGVC,+Phon…
Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah,
Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why
OS-initiated mode?3. Implementation details and testing in TF-AThanks
AllJoanna===============================We run an open technical forum call
for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
don.harbin(a)linaro.org
sudeep.holla(a)arm.com
Souvik Chakravarty
wingers(a)google.com
ajaysp(a)google.com
peckham(a)google.com
Mahesh Sivasubramanian
cozette(a)google.com
mkshah(a)qti.qualcomm.com
ulf.hansson(a)linaro.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Feb 23, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah,
Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why
OS-initiated mode?3. Implementation details and testing in TF-AThanks
AllJoanna===============================We run an open technical forum call
for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
don.harbin(a)linaro.org
sudeep.holla(a)arm.com
Souvik Chakravarty
wingers(a)google.com
ajaysp(a)google.com
peckham(a)google.com
Mahesh Sivasubramanian
cozette(a)google.com
mkshah(a)qti.qualcomm.com
ulf.hansson(a)linaro.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
I have one question about SIP Service Calls range and it's range checking.
Based on DEN0028E SIP Service Calls ranges are
0x82000000-0x8200FFFF SMC32: SiP Service Calls
0xC2000000-0xC200FFFF SMC64: SiP Service Calls
That's the ranges which we are using for implementing SOC specific SMC handlers
and I found that in past it was also added code which is out of this range.
Specifically in Xilinx ZynqMP you can see code like this
if (is_em_fid(smc_fid)) {
return em_smc_handler(smc_fid, x1, x2, x3, x4, cookie, handle,
flags);
}
where EM range is 0x820e0001- 0x820e0003 is out of our range which is assigned
to us. But there is no failure at all that we are out of ranged in spec.
Shouldn't this be enforced by core itself?
That's why I just wanted to know your opinion about it. We will definitely
implement better masking to find out that 0x00fe0000 are all zeros.
But that bit 16 is based on DEN0028E related to smcccv1.3 which I think we are
not supporting now that's why should be 0 too.
But definitely some information about this bit should be useful.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
External email: Use caution opening links or attachments
We are pleased to announce the release of the Trusted Firmware-A LTS version 2.8.0 [1]. To help with the verification and stability of the release, we also created side branches for Trusted Firmware-A Tests [2] and TF-A OpenCI Scripts/Jobs [3].
These went live on 13th February 2023. The trusted-firmware-a repository is now open again.
On behalf of the TF-A LTS project maintainers, I would like to thank the Trustedfirmware.org TF-A Project community for the support and guidance.
Notable features of the TF-A LTS Version 2.8.0 Release are as follows:
TF-A Project Repository
* Resolved issues
* Workarounds for the following CPU errata
* Cortex-A510 erratum 2684597
* Cortex-A710 erratum 2282622
* Cortex-A710 erratum 2768515
* Cortex-A78 erratum 2772019
* Cortex-A78 erratum 2779479
* Cortex-A78C erratum 2772121
* Cortex-X2 erratum 2282622
* Cortex-X2 erratum 2768515
* Cortex-X3 erratum 2615812
* Neoverse N2 erratum 2743089
* Neoverse V1 erratum 2743093
* Neoverse V1 errata 2779461
* Mitigations for the security advisory #10
* Critical bug fixes for the following platforms
* Arm/CSS
* Intel
* Layerscape
* LS1046a
* LX2
* NXP
* ST
Patch Statistics
* 35 Patches merged since v2.8 Nov 2022 release
Please refer to the TF-A LTS [1] changelog for the complete summary of changes.
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/chang…
[2] tf-a-tests.git - Trusted Firmware-A Tests<https://git.trustedfirmware.org/TF-A%2Ftf-a-tests.git/log/?h=refs%2Fheads%2…>
[3] tf-a-ci-scripts.git - Trusted Firmware A (TF-A) CI scripts<https://git.trustedfirmware.org/ci%2Ftf-a-ci-scripts.git/log/?h=refs%2Fhead…>
[4] tf-a-job-configs.git - Trusted Firmware A (TF-A) Jenkins job configs<https://git.trustedfirmware.org/ci%2Ftf-a-job-configs.git/log/?h=refs%2Fhea…>
Hi all,
As you may know, the TF-A project historically used to make heavy use of
weak functions. The code base has numerous examples of them. However,
based on previous discussions, I think we have general consensus in the
TF-A community that the disadvantages of weak functions outweigh their
benefits and for this reason we should discourage introducing new ones.
In practice, I think this policy is already enforced most of the time in
code reviews but I've now posted a patch that makes it explicit in the
project's coding guidelines and provide the rationale behind it.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19398
Note that TF-A maintainers would still be responsible for enforcing this
policy, as the CI system won't flag that for them, mainly because I
think there might be legitimate cases for weak functions in rare
instances so we'd get some false positives from such checks.
We (at Arm) have got plans to gradually convert existing weak functions
to strongly-defined implementations across the code base but this will
take time.
Like I said, I don't expect this change to be too controversial but
please raise any concerns you may have in this email thread or on Gerrit.
Best regards,
Sandrine
Hello,
As announced in the last Tech forum, the code freeze date for the LTS branch was Feb 3, 2023. We have now merged all the patches published on the wiki [1]. The branch is still locked, and all the CI test runs have now been completed. We are trying to root cause one test failure, though.
The RC0 tag was created today, and we request platform owners test the branch [2] on their downstream platforms if they wish.
We are still on track to release on Feb 10 and will publish more updates shortly.
Thanks.
[1] ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>.
[2] trusted-firmware-a.git - Trusted Firmware for A profile Arm CPUs<https://git.trustedfirmware.org/TF-A%2Ftrusted-firmware-a.git/log/?h=refs%2…>
External email: Use caution opening links or attachments
Hello,
As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have now locked the branch and won’t be accepting any more commits.
The list of the commits that will be merged into the LTS branch can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>. If there are commits that we missed or that need to be in the LTS branch, please reach out to us.
We will post more updates shortly.
Thanks.
This event has been updated with a note:
"Updating the agenda for the TF-A Tech Forum session on Feb 9th 2023."
Changed: description
TF-A Tech Forum
Thursday Feb 9, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Title: Firmware update support in the Trusted Services projectPresented by:
Julian HallA reference implementation of the Update Agent has recently been
added to Trusted Services. The implementation provides a toolbox of
reusable components for adding banked FWU support into firmware for
A-Profile devices. The implementation conforms to the Arm FWU-A
specification for compatibility with TF-A and other boot loaders that
recognise FWU-A metadata.===================================We run an open
technical forum call for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC. Feel free to forward this invite to colleagues. Invites are via the
TF-A mailing list and also published on the Trusted Firmware
website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
julian.hall(a)arm.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have started shortlisting the patches for the lts-v2.8 branch.
These are the commits that will be merged into the LTS branch. More details can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://developer.trustedfirmware.org/w/tf_a/tf-a_lts_meeting_minutes/track…>
1. c7e698cfd fix(cpus): workaround for Cortex-X3 erratum 2615812
2. c45791b2f fix(layerscape): fix errata a008850
3. fa0105693 fix(nxp-ddr): use CDDWW for write to read delay
4. 00bb8c37e fix(nxp-ddr): apply Max CDD values for warm boot
5. 07d8e34fd fix(nxp-drivers): fix tzc380 memory regions config
6. c0c157a68 fix(ls1046a): 4 keys secureboot failure resolved
7. 50aa0ea7a fix(lx2): init global data before using it
8. 4daeaf341 fix(sptool): add dependency to SP image
9. 5fb6946ad fix(console): fix crash on spin_unlock with cache disabled
10. ff1d2ef38 fix(el3_runtime): restore SPSR/ELR/SCR after esb
11. c42402cdf fix(intel): fix fcs_client crashed when increased param size
12. 0ca1d8fba fix(layerscape): unlock write access SMMU_CBn_ACTLR
13. b87b02cf1 fix(cpus): workaround for Cortex-A710 erratum 2768515
14. 1cfde8222 fix(cpus): workaround for Cortex-X2 erratum 2768515
15. 377846b65 fix(st): include utils.h to solve compilation error
16. 1cbe42a51 fix(el3_runtime): allow SErrors when executing in EL3
17. 1ee7c8232 fix(cpus): workaround for Neoverse N2 erratum 2743089
18. b10afcce5 fix(cpus): workaround for Cortex-A78 erratum 2772019
19. 31747f057 fix(cpus): workaround for Neoverse V1 erratum 2743093
20. fd37982a1 fix(auth): forbid junk after extensions
21. 72460f50e fix(auth): require at least one extension to be present
22. 06c01b085 fix(libc): properly define SCHAR_MIN
23. 89d85ad0a fix(cpus): workaround for Cortex-A710 erratum 2282622
24. abb8f936f fix(auth): avoid out-of-bounds read in auth_nvctr()
25. f5c51855d fix(auth): properly validate X.509 extensions
26. f9c6301d7 fix(cpus): workaround for Cortex-X2 erratum 2282622
27. 60719e4e0 fix(plat/css): fix invalid redistributor poweroff
28. 00230e37e fix(cpus): workaround for Cortex-A78C erratum 2772121
29. aea4ccf8d fix(cpus): workaround for Cortex-A510 erratum 2684597
If there are commits that we missed or that need to be in the LTS branch, please reach out to us.
Thanks.
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Apologies the LTS Update is for this week on 26th January at 4pm GMT Not
February session.=====Just a reminder that this week the TF-A Tech Forum is
covering a LTS Release update session from the primary maintainers of the
TF-A v2.8 LTS branch:Varun WadekarOkash Khawaja Bipin Ravi Thanks
AllJoanna========We run an open technical forum call for anyone to
participate and it is not restricted to Trusted Firmware project members.
It will operate under the guidance of the TF TSC. Feel free to forward this
invite to colleagues. Invites are via the TF-A mailing list and also
published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
bpeckham(a)google.com
mayurvg(a)gmail.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Feb 23, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Just a reminder that this week the TF-A Tech Forum is covering a LTS
Release update session from the primary maintainers of the TF-A v2.8 LTS
branch:Varun Wadekar <vwadekar(a)nvidia.com> Okash Khawaja
<okash(a)google.com> Bipin Ravi <Bipin.Ravi(a)arm.com>Thanks
AllJoanna===============================We run an open technical forum call
for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi All,
We are in the process of migrating from mbedtls-2.28 support to 3.3 support
we plan to deprecate mbedtls-2.28 support for TF-A 3.0 Release
but would retain support for both 2.28 and 3.3 for TF-A 2.9 lifetime.
There is draft implementation available[1] for code review
which cleanups and prepares for mbedtls-3.3 support but retaining backward
compatibility for mbedtls-2.28.
Please let us know if there any objections to deprecation of mbedtls-2.28 in
TF-A 3.0.
--
Thanks
Govindraj
[1]: https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522
<https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522>
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 382954: Concurrent data access violations (MISSING_LOCK)
/plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo()
________________________________________________________________________________________________________
*** CID 382954: Concurrent data access violations (MISSING_LOCK)
/plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo()
167 dest = (struct constraint_status *)st->value;
168 do {
169 if (dest == NULL) {
170 break;
171 }
172 if (st->type == CONSTRAINT_GET_VALID) {
>>> CID 382954: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "dest->is_valid" without holding lock "spm_lock". Elsewhere, "constraint_status.is_valid" is accessed with "spm_lock" held 5 out of 6 times.
173 dest->is_valid = cpubuckldo_status;
174 } else if (st->type == CONSTRAINT_COND_BLOCK) {
175 dest->is_cond_block = 0;
176 } else if (st->type == CONSTRAINT_GET_ENTER_CNT) {
177 if (st->id == MT_RM_CONSTRAINT_ID_ALL) {
178 dest->enter_cnt += cpubuckldo_enter_cnt;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread [2] about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
to BL31
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review [1], but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in [3]. This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635
[2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[3] https://github.com/OP-TEE/optee_os/issues/5699
Thanks,
Jens
Hello everyone,
A new security vulnerability has been identified in TF-A X.509 parser,
used for trusted boot in BL1 and BL2.
Please note that this vulnerability is *not* exploitable in TF-A
upstream code. Only downstream code might be affected under specific
circumstances.
The security advisory has been published in TF-A documentation and has
all the details:
https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu…
Patches to fix the identified bugs have already been merged in TF-A
tree. The advisory lists the relevant patches.
I would like to thank Demi Marie Obenour from Invisible Things Lab for
responsibly disclosing this security vulnerability to
TrustedFirmware.org, for providing patches to fix the identified bugs
and further harden the X.509 parser, for providing a detailed impact
analysis and for helping put this security advisory together.
Best regards,
Sandrine Bailleux, on behalf of TF-A security team.
This event has been updated with a note:
"Correcting the deletion of the wrong Techforum."
Changed: time
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled with a note:
"No topic this week. Cancelling. Joanna"
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi all,
With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me.
If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held.
Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates:
* 12th January – No topic
* 26th January – LTS Update
* 9th February – No topic
* 23rd February - Tech talk for PSCI OS-initiated mode
Thanks
Joanna
Hello,
I'm working on a project for ChromeOS where we would like to be able to
load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted
rather than during the usual BL32 stage. We would do this via an SMC we
would add which would take the OpTee image from linux and then have EL3
load it and perform the init for SEL-1 at that time.
The reasoning behind this is that it's much easier to update the rootfs
than the FW on our devices, and we can still ensure the integrity of the
OpTee image if we load it early enough after the kernel boots.
The main questions I have are if there are any issues people would be aware
of by loading it after linux boots rather than during the usual BL32 stage?
And I would definitely want to upstream this work if it's something we can
do.
Thanks,
Jeffrey Kardatzke
Google, Inc.
Hi all,
I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is
the branch "arm_cca_v0.3".
When I boot my FVP, I set the following commands:
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \
-C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \
-C cluster0.rme_support_level=2 \
-C cluster1.rme_support_level=2 \
Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the
SMMU Root Control Page should be 0x2b42_0000.
Thus, I add the mapping to this region in plat_arm_mmap[], as:
MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT)
Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on
the manual, its offset is 0x0, so I read 0x2b42_0000.
However, it returns 0x0, which is not what I configured in the boot
commands (I think it should be 0x3).
Can someone tell me the reason for this?
Sincerely,
WANG Chenxu