- TF-A - lists.trustedfirmware.org

by Chenxu Wang

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

3 years, 12 months

3
4
0 0

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

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for 23rd September 2021 16:00 – 17:00 (BST). Agenda: * Title: Realm Management Extension (RME) Support in TF-A * Presented by: Zelalem Aweke * Summary: RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA). In this talk I will give a brief introduction to Arm CCA and RME. Then I will talk about the changes in TF-A to support RME that are expected to be part of the TF-A v2.6 release. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years

1
0
0 0

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

by Yann Gautier

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

4 years

1
0
0 0

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

by scan-admin＠coverity.com

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

4 years

1
0
0 0

Disable the EL2 hypervisor mode

by IS20 Boaz Baron

Hi all, I have a little question, how can I disable the hypervisor mode so EL2 will be just bridge to EL1 ns? (I mean without touching common ARM code only the platform-oriented code) Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years

2
1
0 0

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

by joanna.farley＠arm.com

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

4 years

1
0
0 0

include/plat/common in project path?

by Yann Gautier

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

4 years

1
0
0 0

Re: [TF-A] Secure boot without FIP

by Yann Gautier

On 7/28/21 10:50 AM, guillaume pivetta via TF-A wrote: > Hi, I’m trying to implement a secure boot on a STM32MP1 without using > the FIP file. > Hi Guillaume, Sorry for this very late reply. > For now , I am not able to use FIP format during the boot process so I > use a depreciated boot process with TF-Av2.2 as FSBL and U-Boot as SSBL > to boot my Board. > That's quite an old software. If you can, I'd suggest you update the software to the version delivered by ST, based on a v2.4 label. The sources are available there: https://github.com/STMicroelectronics/arm-trusted-firmware And you should take the v2.4-stm32mp branch. In this software, FIP is available, and with a better support for TUSTED_BOARD_BOOT. > My boot process do Romcode -> TF-A (BL2) -> SP_min (BL32) -> U-Boot > (BL33) -> Linux kernel > > I succefully implemented signature authentification between U-Boot and > Linux image, but between TF-A and U-Boot it’s a little bit harder. > > I learned on ST wiki how to sign my u-boot binary with the > STM32MP_SigningTool_CLI, but when I sign my binary with a custom private > key, TF-A don’t authentified it on boot, even if i tryed to pass my key > to TF-A at compilation time with the BL33_KEY argument, which i think is > dedicated to the FIP usage. > > I found, in the sources of TF-A, what I think being a developpement key, > named « arm_rotpk_ecdsa.pem ». > > And when I sign my binary with this key, I am able to perform the > signature check and continu my boot process. So I tryed to change this > key with a custom one and recompile TF-A to update the key in the final > binary, but it seem that it is not so simple. > > I found yesterday that the auth_mod_init() function wasn’t call because > I had forgotten the TUSTED_BOARD_BOOT=1 compilation argument. But when I > activate it, the compilation doesn’t work and i see > > « build/arm-trusted-firmware-v2.2/bl2/bl2_main.c:91: undefined reference > to `auth_mod_init' » > > Whitch traditionnaly append when linker don’t find the .o where the > functions are implemented. > > I would like to know if it is possible to implement some kind of > authentification with custom keys without FIP and if yes where can i > find some hints/ressources/tutorial ? > > I don’t find a lot of ressources about secure boot without FIP so I hope > you will be able to help me. > > If you can switch to a newer software with FIP, you can check: https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FIP Else, the page that could help you is there: https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_secure_boot If you need more help, the better is to use the links given at the bottom of the wiki pages: ST Support Center (https://community.st.com/s/onlinesupport) or ST Community MPU Forum (https://community.st.com/s/topic/0TO0X0000003u2AWAQ/stm32-mpus). Best regards, Yann

4 years, 1 month

1
0
0 0

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

by joanna.farley＠arm.com

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

4 years, 1 month

1
0
0 0

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

by Ming Huang

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

4 years, 1 month

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A