- TF-A - lists.trustedfirmware.org

by Olivier Deprez

Hi, Stepping back to the initial thread, I now miss the rationale for routing interrupts to EL3. "I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient." If your intent is to dump user process page tables, that's something to do using the linux kernel mm framework, and not necessarily at EL3. Not sure why a "linux driver is not sufficient". More inputs on this may be beneficial. Nevertheless if you need a service in EL3 to do "introspection", you would rather write a form of SiP service accessed through SMC (not necessarily routing interrupts through FIQ). As for the code snippets, replacing vbar_el3 with your own vector table looks wrong. This will break any service call back into EL3 when linux is booted (e.g. PSCI calls....) If you really want to route interrupts to EL3 you shall use the Interrupt Handling Framework as Manish suggested. e.g. uint64_t fiq_handler(uint32_t id, uint32_t flags, void *handle, void *cookie) { [...] return 0; } void register_my_interrupt(void) { int32_t rc, flags = 0; plat_ic_set_interrupt_type(intid, INTR_TYPE_EL3); set_interrupt_rm_flag(flags, NON_SECURE); rc = register_interrupt_type_handler(INTR_TYPE_EL3, fiq_handler, flags); NOTICE("register_interrupt_type_handler %d\n", rc); } Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 February 2021 02:15 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] 1023 spurious interrupt Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

5 years, 1 month

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by AT&T

Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

5 years, 1 month

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Manish Pandey2

I have seen same thing in your previous thread also, could you please confirm that the build option GICV2_G0_FOR_EL3 instead of GICV2_GO_FOR_EL3 (zero instead of "O"). ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 02 February 2021 21:03 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Spurious interrupt 1023 UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. As for your questions Olivier: The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Olivier Deprez<mailto:Olivier.Deprez@arm.com> Sent: Monday, February 1, 2021 2:36 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; AT&T<mailto:iburres@att.net> Subject: Re: [TF-A] Spurious interrupt 1023 Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 1 month

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Olivier Deprez

Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 1 month

2
1
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() ________________________________________________________________________________________________________ *** CID 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() 754 PI_VERSION_CODE = 0x2041U; /* G2M */ 755 } 756 757 ddr_getval_ach(_reg_PI_VERSION, (uint32_t *)tmp_ach); 758 err = 0U; 759 foreach_vch(ch) { >>> CID 366312: Uninitialized variables (UNINIT) >>> Using uninitialized value "PI_VERSION_CODE". 760 if (tmp_ach[ch] != PI_VERSION_CODE) { 761 err = 1U; 762 } 763 } 764 return err; 765 } ** CID 366311: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 366311: Memory - corruptions (OVERRUN) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 3156 in rdqdm_man1() 3150 } 3151 } 3152 } 3153 if ((prr_product == PRR_PRODUCT_M3) && 3154 (prr_cut <= PRR_PRODUCT_10)) { 3155 for (slice = 0U; slice < SLICE_CNT; slice++) { >>> CID 366311: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "slice" (which evaluates to 24) in call to "rdqdm_man1_set". 3156 rdqdm_man1_set(ddr_csn, ch, slice); 3157 } 3158 } 3159 } 3160 ddrphy_regif_idle(); 3161 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 1 month

1
0
0 0

Spurious interrupt 1023

by AT&T

I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D

5 years, 1 month

1
0
0 0

Re: [TF-A] PK hash verify after signature virified

by Manish Badarkhe

Hi Bin Wu, Thanks for coming up with this question. As per the below signature verification code, you raised a valid point that signature gets verified before ROTPK hash verification. 1. Get ROTPK hash from the platform (Using platform implemented method e.g., HW register). 2. Extract ROTPK from the image itself. 3. Use ROTPK to verify the image signature. 4. Calculate the hash of ROTPK and compare it against the hash received in step[1]. But we can't see any concern as the system fails to boot anyways at step [4] if the ROTPK gets corrupted. Regards Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅隆) via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Friday, 29 January 2021 at 07:55 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] PK hash verify after signature virified Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

5 years, 1 month

1
0
0 0

PK hash verify after signature virified

by 吴斌(郅隆)

Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

5 years, 1 month

1
0
0 0

TF-A Tech Forum Agenda @ Thr 28th January 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 28th January 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Automotive Enhance (AE) Architecture Support Requirements Discussion * Presented by Manish Pandy and Manish Badarkhe * A discussion on the needs for the Automotive Enhance (AE) space and how TF-A can support that with CPU and GIC capabilities. The goal is to follow-up the recent email to the TF-A mailing list and try and understand project needs in this space by talking to the project community. 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. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

5 years, 1 month

1
0
0 0

Re: [TF-A] Gather GIC changes required for safety critical machines

by Varun Wadekar

<Cc alias> I guess, something went wrong when I clicked "Reply all" the first time. Manish, can you also talk about the tasks that Arm is willing to work on? Then we can ask for volunteers for the remaining ones. I'm sure, NVIDIA will contribute as this topic is close to our heart. -Varun From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Monday, January 25, 2021 8:05 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com>; Robin Randhawa <Robin.Randhawa(a)ARM.com>; Ed Doxat <Ed.Doxat(a)arm.com>; Joanna Farley <joannafarley(a)icloud.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>; Doug Richmond <Doug.Richmond(a)arm.com> Subject: Re: Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments ++ Other Arm folks Just realized that Varun has reduced the recipients(guess that was intentional) ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 25 January 2021 10:15 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: Re: Gather GIC changes required for safety critical machines Hi Varun, We are trying to do both, based on interest from community we will prioritize these tasks. The reason why we can't do all the asks (mentioned in the list) ourselves is, currently we do not have "use cases/platforms" to test all the features, so we would rely on wider community to understand the requirements and work together to develop/test those features. Thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 22 January 2021 17:46 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: RE: Gather GIC changes required for safety critical machines HI Manish, Thanks for starting this discussion. The list captures all the functionalities that are useful and interesting to us. Trying to understand the ask - are you trying to get feedback to allow you to prioritize the feature list? Or are you asking for the community to rate importance of these requirements? I am afraid, if there isn't enough interest the list might be trimmed which would be an absolute shame. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A Sent: Friday, January 22, 2021 8:02 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: [TF-A] Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 1 month

1
0
0 0

[PATCHv9 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v9: - cosmetic changes (move if from patch2 to patch3, rename function name and define). v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

2
4
0 0

Gather GIC changes required for safety critical machines

by Manish Pandey2

Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish

5 years, 1 month

1
0
0 0

[PATCHv8 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

3
9
0 0

[PATCHv7 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 117 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 174 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

2
8
0 0

[PATCHv6 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

2
4
0 0

[PATCHv4 0/2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (2): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 40 +++++++++++++++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 3 ++ 6 files changed, 118 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

4
14
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 14 Jan 2021 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Cancelled - see the mail from Joanna for more details" 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 14 Jan 2021 16:00 – 17:00 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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 1 month

1
0
0 0

CANCELLED: TF-A Tech Forum Agenda @ Thr 14th January 2021 16:00-1700 GMT

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as the subject I had hoped to get presented is not ready and I don’t have any alternative for this slot. I will look to have something for the next session on 28th January. Apologies for the late notice. Cancellations of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

5 years, 1 month

1
0
0 0

[PATCHv5 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

1
3
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() 328 SMC_RET1(handle, (uint64_t)ret); 329 330 case PM_SET_MAX_LATENCY: 331 ret = pm_set_max_latency(pm_arg[0], pm_arg[1]); 332 SMC_RET1(handle, (uint64_t)ret); 333 >>> CID 365287: Control flow issues (MISSING_BREAK) >>> The case for value "PM_GET_API_VERSION" is not terminated by a 'break' statement. 334 case PM_GET_API_VERSION: 335 /* Check is PM API version already verified */ 336 if (pm_ctx.api_version >= PM_VERSION) { 337 if (!ipi_irq_flag) { 338 /* 339 * Enable IPI IRQ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 1 month

1
0
0 0

Re: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Manish Pandey2

Hi To understand the interrupt handling in TF-A, i recommend you go through https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo… To debug your problem, you need to first check if the timer interrupt is generated as FIQ and check whether it indeed is trapped in EL3 (checking SCR_EL3.FIQ=1). Regarding build errors while adding .S files and your assembly implementation, it will be better if you share your code (may be pushing a patch on https://review.trustedfirmware.org). Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 January 2021 17:56 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

5 years, 2 months

2
1
0 0

[PATCHv3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 ++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 85 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 115 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..0d0680c9f7 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,85 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/log.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

3
3
0 0

Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Ian Burres

I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. >From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail for Windows 10

5 years, 2 months

1
0
0 0

[PATCHv2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 84 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 114 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..f5868653b3 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,84 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

1
0
0 0

[PATCH] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Regards, Maxim. hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 83 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 113 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..dded12381b --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,83 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + printf("qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

2
1
0 0

Build error with GCC 10.2-2020.11

by Manish Badarkhe

Hi Carlo Alexei created a patch for testing TF-A/TFTF builds with the toolchain GCC 10.2-2020.11 https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/7733 which flagged build errors for plat/amlogic/axg platform, please see below: Build command lines: make CROSS_COMPILE=aarch64-none-elf- PLAT=axg SPD=opteed DEBUG=1 V=1 fiptool all make AML_USE_ATOS=1 CROSS_COMPILE=aarch64-none-elf- PLAT=axg DEBUG=1 V=1 fiptool all plat/amlogic/axg/axg_pm.c: In function 'axg_pwr_domain_off': plat/amlogic/axg/axg_pm.c:124:43: error: array subscript 2 is above array bounds of 'const plat_local_state_t[2]' {aka 'const unsigned char[2]'} [-Werror=array-bounds] 124 | if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ In file included from plat/amlogic/axg/axg_pm.c:14: include/lib/psci/psci.h:270:28: note: while referencing 'pwr_domain_state' 270 | plat_local_state_t pwr_domain_state[PLAT_MAX_PWR_LVL + U(1)]; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Makefile:1103: recipe for target '/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o' failed make: *** [/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o] Error 1 Please help to resolve this issue. Thanks Manish Badarkhe

5 years, 2 months

1
0
0 0

Re: [TF-A] Interrupt about ff-a spec

by Achin Gupta

Hi Feng, On Fri, Dec 18, 2020 at 04:41:37PM +0000, Chen Feng via TF-A wrote: > Hi, > > While reading the Arm Firmware Framework for Armv8-A > https://developer.arm.com/documentation/den0077/latest > > I do not find the API that for a sp to request vIRQ, or do I miss something. > > Is this some private API that is implementing defined FF-A IDs? Is what you have in mind is an ABI that allows SP0 to raise an interrupt in SP1? Could you please provide more information about your use case? cheers, Achin > > > -- > cheers, > feng > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

3
3
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Chen Feng

Hi all, I have a similar but different question here :) Why not the tf-a support both smpd and tspd. Since the vendor's teeos that has not support ff-a interface currently. With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services? It seems to need some tlb maintenance, but it seems work. On 2020/11/23 3:27 下午, Achin Gupta via TF-A wrote: > Hi Heyi, > > Happy to discuss the detail but the short answer is no. > > Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. > > From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. > > Cheers, > Achin > > On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi All, > > On some platforms there may be requirements to run both TEE and SPM_MM > instances, such as providing TEE services on server platforms. > > Do TF-A support this scenario? If it doesn't, do it make sense to add > such support? > > Thanks, > > Heyi > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- cheers, feng

5 years, 2 months

2
3
0 0

Interrupt about ff-a spec

by Chen Feng

Hi, While reading the Arm Firmware Framework for Armv8-A https://developer.arm.com/documentation/den0077/latest I do not find the API that for a sp to request vIRQ, or do I miss something. Is this some private API that is implementing defined FF-A IDs? -- cheers, feng

5 years, 2 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. 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 and being prepared: 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 and shared on the TF-A mailing list. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

5 years, 2 months

1
0
0 0

Re: [TF-A] Question about validity period of X509 certificate

by Andrej Butok

Hello Masato Fukumori, To check a "validity period" of a X 509 certificate, you must be sure that your system date & time is set, correct and not changed. Do you have a reliable way to achieve this? Best regards, Andrej Butok From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of fukumori.masato--- via TF-A Sent: Thursday, December 10, 2020 2:23 PM To: 'tf-a(a)lists.trustedfirmware.org' <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Question about validity period of X509 certificate Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

5 years, 3 months

2
4
0 0

Question about validity period of X509 certificate

by fukumori.masato＠fujitsu.com

Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

5 years, 3 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() 295 { 296 unsigned int pstate = psci_get_pstate_type(power_state); 297 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 298 unsigned int cpu = plat_my_core_pos(); 299 300 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 301 return PSCI_E_INVALID_PARAMS; 302 } 303 304 if (pstate == PSTATE_TYPE_STANDBY) { 305 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 306 } else { ** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() ________________________________________________________________________________________________________ *** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() 36 * API 37 ************************************************/ 38 void ptp3_init(unsigned int core) 39 { 40 unsigned int _core; 41 >>> CID 364145: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 42 if (core >= PTP3_CFG1_CPU_START_ID) { 43 if (core < NR_PTP3_CFG1_CPU) { 44 /* update ptp3_cfg1 */ 45 ptp3_write( 46 ptp3_cfg1[core][PTP3_CFG_ADDR], 47 ptp3_cfg1[core][PTP3_CFG_VALUE]); ** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() ________________________________________________________________________________________________________ *** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() 70 } 71 } 72 } 73 74 void ptp3_deinit(unsigned int core) 75 { >>> CID 364144: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 76 if (core >= PTP3_CFG1_CPU_START_ID) { 77 if (core < NR_PTP3_CFG1_CPU) { 78 /* update ptp3_cfg1 */ 79 ptp3_write( 80 ptp3_cfg1[core][PTP3_CFG_ADDR], 81 ptp3_cfg1[core][PTP3_CFG_VALUE] & 82 ~PTP3_CFG1_MASK); 83 } 84 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 3 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 31 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. 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 31 Dec 2020 16:00 – 17:00 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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 3 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. 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 3 Dec 2020 16:00 – 17:00 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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Achin Gupta

Hi Heyi, Happy to discuss the detail but the short answer is no. Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. Cheers, Achin On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

3
7
0 0

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

by Joanna Farley

Apologies, I need to cancel this weeks TF-A Tech Forum session on 3rd December due to clashing events for Arm attendees. Next meeting will be 17th December which will be the last session of 2020. 31st December session is also cancelled with the first 2021 session being 14th January 2021. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 3 December 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 3 months

1
0
0 0

Does TF-A support to load and run both TEE and SPM_MM?

by Heyi Guo

Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi

5 years, 3 months

1
0
0 0

Re: [TF-A] [PATCH] plat/qemu/qemu_sbsa: Include libraries for Cortex-A72

by Jens Wiklander

Hi Tanmay, Please upload the patch at https://review.trustedfirmware.org/, for details see https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Thanks, Jens On Thu, Nov 19, 2020 at 7:28 PM Tanmay Jagdale <tanmay.jagdale(a)linaro.org> wrote: > > Include libraries needed to emulate Cortex-A72 in sbsa-ref target of Qemu. > > Signed-off-by: Tanmay Jagdale <tanmay.jagdale(a)linaro.org> > --- > plat/qemu/qemu_sbsa/platform.mk | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk > index 1a4a2db02..a8036f622 100644 > --- a/plat/qemu/qemu_sbsa/platform.mk > +++ b/plat/qemu/qemu_sbsa/platform.mk > @@ -43,7 +43,8 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ > > BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > - lib/cpus/aarch64/cortex_a57.S > + lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S > > BL2_SOURCES += drivers/io/io_semihosting.c \ > drivers/io/io_storage.c \ > @@ -72,6 +73,7 @@ QEMU_GIC_SOURCES := ${GICV3_SOURCES} \ > BL31_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S \ > lib/semihosting/semihosting.c \ > lib/semihosting/${ARCH}/semihosting_call.S \ > plat/common/plat_psci_common.c \ > -- > 2.29.2 >

5 years, 3 months

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 3 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 19th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Trace-based Code Coverage Tooling for Firmware Projects * Presented by Basil Eljuse & Saul Romero * Summary * TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project. * Optional TF-A Mailing List Topic Discussions 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 and being prepared: 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 and shared on the TF-A mailing list. Thanks Joanna

5 years, 3 months

1
0
0 0

Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available

by Manish Badarkhe

Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 3 months

1
0
0 0

atf-a with optee-os for firefly-rk3399

by Piotr Lobacz

Hi All, i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50... Can anybody help me solving this issue or point me to some solution? Thanks in advance. BR Piotr Łobacz [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.

5 years, 3 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Soby Mathew

Hi Julius, The TF-A build sets the `-mstrict-align` compiler option, that means that the compiler will generate only aligned accesses as default. So disabling the check at runtime, seems `unaligned` with the compiler option IMO. The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO. > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. TF-A has linker symbol references and non-trivial linker section manipulations at runtime and these have previously triggered alignment errors when binary layout changed due to code issues. Disabling the alignment check at runtime means these errors would have remained undetected and would have resulted in more obscure crash at runtime or even a vulnerablility. In some cases, only the RELEASE builds (DEBUG=0) triggered the alignment fault. > There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense). Agree. But I am failing to understand why the unaligned accesses came to be there in the first place. My worry is, if this was not intended by the programmer, this might as well be a bug that will remain undetected if the alignment check is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 10 November 2020 02:31 > To: raghu.ncstate(a)icloud.com > Cc: tf-a <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Alignment fault checking in EL3 > > > >>. What I am worried about is mistakes and oversights that slip > > >>through testing and then cause random or even attacker-controllable > > >>crashes in production > > > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing > the relation between the crash and SCTLR.A bit. If there are oversights that > slip through testing and an attacker can cause a crash, there is > vulnerability/bug. > > If there is something that slipped through, that causes a data > abort(perhaps address not mapped in the translation tables), would we turn > off the MMU ? > > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. If you have examples to the contrary please let me know, but > as far as I am aware letting an unaligned access through should always work > and will always result in the behavior the programmer intended (other than > maybe contrived cases where device address space is mapped with a non- > Device memory type, which is already very wrong for plenty of other reasons > and should never happen). The only negative consequence is that the access > may take slightly longer than if it were aligned. I do understand the desire to > be able to shake out unaligned accesses during development and testing > > I don't think the comparison to a data abort works because obviously with a > data abort the program usually can't just continue and still assume its internal > state is valid.

5 years, 3 months

2
2
0 0

FW: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A

by Matteo Carlini

Cross-posting on the TF-A mailing list too for interested people to attend the kickoff meeting listed below hosted by Linaro. Thanks Matteo -----Original Message----- From: Linaro-open-discussions <linaro-open-discussions-bounces(a)op-lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions Sent: 10 November 2020 10:21 To: linaro-open-discussions(a)op-lists.linaro.org Subject: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A Hi all, As previously announced we are hosting a kickoff meeting for the above topic/project. The meeting has been added to the linaro-open-discussions calendar, according to the below. Feel free to join us on Thursday this week! Kind regards Ulf Hansson, Linaro KWG When: Thursday Nov 12, 16:00-17:00 CET. Agenda: 1. Introduction. 2. Update of the current support in Linux. 3. Collaborations. 4. Technical things. 5. Other matters. To join the Zoom Meeting: https://linaro-org.zoom.us/j/97261221687 Meeting ID: 972 6122 1687 One tap mobile +13462487799,,97261221687# US (Houston) +16465588656,,97261221687# US (New York) Dial by your location +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) Meeting ID: 972 6122 1687 Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE -- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Julius Werner

> >>. What I am worried about is mistakes and > >>oversights that slip through testing and then cause random or even > >>attacker-controllable crashes in production > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug. > If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ? Well, my assumption is that performing an unaligned access cannot be a vulnerability. If you have examples to the contrary please let me know, but as far as I am aware letting an unaligned access through should always work and will always result in the behavior the programmer intended (other than maybe contrived cases where device address space is mapped with a non-Device memory type, which is already very wrong for plenty of other reasons and should never happen). The only negative consequence is that the access may take slightly longer than if it were aligned. I do understand the desire to be able to shake out unaligned accesses during development and testing, but at least in a production build I think taking that performance hit would always be preferable to a crash. I don't think the comparison to a data abort works because obviously with a data abort the program usually can't just continue and still assume its internal state is valid.

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, A lot of the rationale for the default initialization is not listed in the documentation and I do think perhaps we can do better as at the end of the day it’s decisions around platform ports and how they are going to be deployed in products that may influence decisions here for changing the defaults. Your thoughts around attacker control able crashes are a valid one. I don’t think any one setting is all pros with no cons and platform providers need to make decisions but I think the default code with the settings is more likely to flush out alignment bugs and although I don’t have specific examples any bug could play a part in future vulnerability so best to flush them out rather than lie hidden. It could be said that in the reference implementation a known crash may be better than a more nebulous unknown behaviour that could come with an undetected bug that could later be taken advantage of. The use a DEBUG flag is an idea but we have all seen debug builds not operating like production builds so the value may be lost here. It’s why on reviewing our documentation on seeing your post I think we could do better to explain the rationale for the settings in TF-A so platform owners can be better informed and override default settings if they really feel they have the need. Cheers Joanna ________________________________ From: Julius Werner Sent: Monday, November 9, 2020 10:42 PM To: Joanna Farley Cc: raghu.ncstate(a)icloud.com; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Alignment fault checking in EL3 Hi Joanna, Thank you for your detailed response. I was mostly wondering if this was a deliberate choice or just something someone wrote this way once and nobody ever thought about again. Since it sounds like it is intentional, I'll try to understand your rationale better. > Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. I'm curious, can you elaborate on that? I can't really think of a scenario where lack of alignment checking can really make code behave in an unintentional way. (I don't think Raghu's scenario of accessing MMIO registers works because those registers should be mapped with a Device memory type anyway, and that memory type enforces aligned accesses regardless of the SCTLR.A flag.) If there truly are security concerns with this I can understand your approach much better. > Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense).

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, Talking to the team here its has always been felt it is best practise to forbid unaligned data accesses in Arm's embedded projects. That's the reason TF-A also enforces the build options: -mno-unaligned-access (AArch32) and -mstrict-align (AArch64). In the TF-A documentation [1] SCTLR_EL3.A and other settings are listed in the Architectural Initialisation section. There is thought to be only a few cases where unaligned access are correct and intentional and most are defects that should be caught early and not in production and as such it is better to detect unaligned data access conditions early in a platform porting, rather than in the field especially if there is no firmware update capability. Alignment faults should be treated as fatal as they should never happen in production when components have been designed as such from the beginning. Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. We can of course provide better rationalisation based on the above in our documentation to provide platforms porting efforts better guidance. It is after all up to partners in their platform ports to make appropriate decisions for their ports where settings could be changed however the upstreamed reference code should follow the settings we have which are felt to be best practices for TF-A. It is known other projects follow other practices and that is fine if that works for them. Once a project enables unaligned accesses, it's very hard to go back again since it's likely that code that does unaligned accesses will slowly get added to the project. However for TF-A maintaining the current settings is felt to be the best approach when weighing up the costs and benefits. Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. Thanks Joanna [1] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.h… On 09/11/2020, 17:47, "TF-A on behalf of Raghu Krishnamurthy via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes? -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

3
2
0 0

Re: [TF-A] Alignment fault checking in EL3

by raghu.ncstate＠icloud.com

Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 4 months

1
0
0 0

Alignment fault checking in EL3

by Julius Werner

Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A