- TF-A - lists.trustedfirmware.org

Re: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Dan Handley

Hi Sandeep Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform. There is no explicit watchdog interrupt handling functionality in TF-A. If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter. > Q1- What happens if core is stuck and interrupts are not taken. It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent. > Or it has to be registered as a RAS priority exception. I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running. Regards Dan. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep Tripathy via TF-A Sent: 27 August 2020 12:14 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3 Hi, Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. I have some query on how TF-A plans to implement this. Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. If WS1 were to another subsystem (eg: SCP) then it would take action. In current scheme is it the secure sbsa wdg expected to detect such hang ? Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c index 79c6f26..9683ef8 100644 --- a/drivers/arm/sbsa/sbsa.c +++ b/drivers/arm/sbsa/sbsa.c @@ -40,3 +40,26 @@ + +#define weak plat_sbsa_nt_wdog_ws1_handle +#define weak plat_sbsa_t_wdog_ws0_handle +void sbsa_wdog_handler(int id) +{ + if (id == SBSA_NT_WDG_WS1_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_nt_wdog_ws1_handle(); + } else if (id == SBSA_T_WDG_WS0_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_t_wdog_ws0_handle(); + } + /* EOI and reset , log what else */ + psci_systrem_reset2(); +} + +void sbsa_wdog_hander_init(void) +{ +#if EXCEPTION_HANDLING_FRAMEWORK + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); +#endif +} Thanks Sandeep

4 years, 8 months

1
0
0 0

[query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Sandeep Tripathy

Hi, Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. I have some query on how TF-A plans to implement this. Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. If WS1 were to another subsystem (eg: SCP) then it would take action. In current scheme is it the secure sbsa wdg expected to detect such hang ? Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c index 79c6f26..9683ef8 100644 --- a/drivers/arm/sbsa/sbsa.c +++ b/drivers/arm/sbsa/sbsa.c @@ -40,3 +40,26 @@ + +#define weak plat_sbsa_nt_wdog_ws1_handle +#define weak plat_sbsa_t_wdog_ws0_handle +void sbsa_wdog_handler(int id) +{ + if (id == SBSA_NT_WDG_WS1_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_nt_wdog_ws1_handle(); + } else if (id == SBSA_T_WDG_WS0_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_t_wdog_ws0_handle(); + } + /* EOI and reset , log what else */ + psci_systrem_reset2(); +} + +void sbsa_wdog_hander_init(void) +{ +#if EXCEPTION_HANDLING_FRAMEWORK + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); +#endif +} Thanks Sandeep

4 years, 8 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() ________________________________________________________________________________________________________ *** CID 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() 48 49 static int wait_for_done(uint16_t apid) 50 { 51 unsigned int timeout = 100; 52 53 while (timeout-- != 0U) { >>> CID 361485: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618056 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618056 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 54 uint32_t status = mmio_read_32(REG_ARB_STATUS(apid)); 55 if ((status & ARB_STATUS_DONE) != 0U) { 56 if ((status & ARB_STATUS_FAILURE) != 0U || 57 (status & ARB_STATUS_DENIED) != 0U || 58 (status & ARB_STATUS_DROPPED) != 0U) { 59 return status & 0xff; ** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() ________________________________________________________________________________________________________ *** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() 66 return ARB_FAKE_STATUS_TIMEOUT; 67 } 68 69 static void arb_command(uint16_t apid, uint8_t opcode, uint32_t addr, 70 uint8_t bytes) 71 { >>> CID 361484: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618048 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618048 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 72 mmio_write_32(REG_ARB_CMD(apid), (uint32_t)opcode << 27 | 73 (addr & 0xff) << 4 | (bytes - 1)); 74 } 75 76 int spmi_arb_read8(uint32_t addr) 77 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] TF-A Gerrit access permissions currently broken.

by Joanna Farley

Things should be back to normal. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Wednesday, 26 August 2020 at 12:51 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] TF-A Gerrit access permissions currently broken. Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

4 years, 8 months

1
0
0 0

TF-A Gerrit access permissions currently broken.

by Joanna Farley

Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

4 years, 8 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 27th August 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 27th August 2020 16:00 – 17:00 (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: * TF-A Errata Process – Presented by Bipin Ravi * Bug Review Committee (BRC) & Categorization of Errata * Software Developers Errata Notice (SDEN) & Product Errata Notice (PEN) * What TF-A Implements * How TF-A Implements * Testing 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

4 years, 8 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Varun Wadekar

<Cc alias> -----Original Message----- From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Sent: Tuesday, August 25, 2020 8:59 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Soby Mathew <Soby.Mathew(a)arm.com> Subject: RE: [TF-A] [RFC] Api to power down all cores Thanks, I will use callback as param to get rid of the 'plat*'. 'void psci_stop_other_cores(void (*stop_func)(uregister_t mpidr))' Platform can call like .. psci_stop_other_cores(ipi_send_stop); I will update the patch tomorrow. This api is not invoked by psci generic functions. So I think that should suffice your concern. Anyways I will take care any other suggestions. IPI implementation is under flag 'IPI_SUPPORT'. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/ Thanks Sandeep > -----Original Message----- > From: Varun Wadekar [mailto:vwadekar@nvidia.com] > Sent: Tuesday, August 25, 2020 9:11 AM > To: Soby Mathew; Sandeep Tripathy > Subject: RE: [TF-A] [RFC] Api to power down all cores > > Hi, > > In addition to the suggestions already posted, we should provide a > build flag or dynamic knob to allow platforms to disable this feature. > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-A > Sent: Friday, August 21, 2020 3:57 AM > To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] [RFC] Api to power down all cores > > External email: Use caution opening links or attachments > > > Hi Sandeep, > Thanks for the clarification. I too think this has general utility and > since you need access to internal PSCI data to perform the > functionality , exporting a utility function from PSCI for platforms > to invoke seems the right thing to do. > The small concern I have is using the `plat_*` namespace as this is a > utility function invoked by the platform and another porting layer > beneath it seems out of place. > > I would suggest to add a parameter to stop_other_cores(), this could > be either the IPI number or a callback function to trigger the IPI. > This allows to provide the platform specific details without `plat_*` > API. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > > Sent: 21 August 2020 07:17 > > To: Soby Mathew <Soby.Mathew(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: RE: [TF-A] [RFC] Api to power down all cores > > > > Hi Soby, > > I realize using term 'PSCI API' in rfc tag is misleading like Achin > > mentioned in gerrit. > > > > Here I wanted to have a generic API to 'stop_other_cores' in > > secure world. > > The usage is platform firmware specific. > > Implementation of 'stop_other_cores' depends on a generic 'IPI' > > support > (1). > > It leverages the existing EHF. So I feel it is not adding and > > complexity or overhead in normal execution path. > > > > 'stop_other_cores' API implementation depends on some psci private > > functions to traverse the pd nodes and extract MPIDRs for target pe > > list. That was the reason to put the function within psci lib. So > > there are > two things. > > 1- Does this idea of 'stop_other_core' api qualify to be generic > > 2- Does a generic IPI layer make sense > > > > Thanks > > Sandeep > > > -----Original Message----- > > > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > > > Sent: Thursday, August 20, 2020 8:54 PM > > > To: Sandeep Tripathy > > > Cc: tf-a(a)lists.trustedfirmware.org > > > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > > > > > Hi Sandeep, > > > Just to understand better, if there is a secure side > > > panic/watchdog interrupt, then the secure side is already able to > > > do such an intervention without the availability of a PSCI API to the NS side. > > > > > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > > > PSCI_SYSTEM_OFF APIs can be invoked which then does the > > > appropriate actions. From my reading, the PSCI specification > > > doesn't prevent firmware implementation of the reset and off API's > > > from doing the kind of implementation as per your proposal. > > > > I intend to do 'stop_other_cores' in platform extension of > > 'plat_system_resetx()', secure side watchdog expiry/ > > plat_panic_handler(). > > > > > > > > Best Regards > > > Soby Mathew > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep > > > > Tripathy via TF-A > > > > Sent: 19 August 2020 16:42 > > > > To: tf-a(a)lists.trustedfirmware.org > > > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > > > > > Hi, > > > > I am proposing to have a generic api in psci lib which can be > > > > used to > > > force > > > > power down all other cores from any initiating core analogous to > > > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by > > > > EL1/EL2 software. > > > > > > > > Platforms may use this api in case of secure side panic, secure > > > > watchdog interrupt handling or if required in certain types of > > > > warm resets. The usage > > > is > > > > platform dependent. > > > > > > > > This depends on a generic implementation of secure IPI (1) which > > > > uses EHF > > > to > > > > handle IPI at platform defined priority. We probably require > > > > more types of secure IPIs. > > > > > > > > Please review the series > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5 > > > > 32 > > > > 4 > > > > > > > > diff --git a/lib/psci/psci_system_off.c > > > > b/lib/psci/psci_system_off.c index > > > > 141d69e..011aaa6 100644 > > > > --- a/lib/psci/psci_system_off.c > > > > +++ b/lib/psci/psci_system_off.c > > > > @@ -10,10 +10,44 @@ > > > > #include <arch_helpers.h> > > > > #include <common/debug.h> > > > > #include <drivers/console.h> > > > > +#include <drivers/delay_timer.h> > > > > #include <plat/common/platform.h> > > > > > > > > #include "psci_private.h" > > > > > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { > > > > + int idx, this_cpu_idx, cnt; > > > > + > > > > + this_cpu_idx = plat_my_core_pos(); > > > > + > > > > + /* Raise G0 IPI cpustop to all cores but self */ > > > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > > > + if ((idx != this_cpu_idx) && > > > > + (psci_get_aff_info_state_by_idx(idx) == > > > > AFF_STATE_ON)) { > > > > + > > > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > > > + } > > > > + } > > > > + > > > > + /* Wait for others cores to shutdown */ > > > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; > > > > + cnt++) > > > { > > > > + if (psci_is_last_on_cpu()) > > > > + break; > > > > + mdelay(1); > > > > + } > > > > + > > > > + if (!psci_is_last_on_cpu()) { > > > > + WARN("Failed to stop all cores!\n"); > > > > + psci_print_power_domain_map(); > > > > + } > > > > +} > > > > +#endif > > > > + > > > > > > > > (1) > > > > RFC: ipi: add ipi feature > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > > > a/+/5323/1 > > > > > > > > Thanks > > > > Sandeep > > > > -- > > > > TF-A mailing list > > > > TF-A(a)lists.trustedfirmware.org > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

1
0
0 0

[Request for review] Downstream patches from Tegra repos

by Varun Wadekar

Hello team, Requesting reviews for the latest patches [1] form our internal repos for Tegra platforms. I have updated the verification steps for each patch in the comments to help answer some questions. Thanks in advance. -Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-08252020%22+…

4 years, 8 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() ________________________________________________________________________________________________________ *** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() 43 44 /******************************************************************************* 45 * SPM Core context on CPU based on mpidr. 46 ******************************************************************************/ 47 spmd_spm_core_context_t *spmd_get_context_by_mpidr(uint64_t mpidr) 48 { >>> CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) >>> Using variable "plat_core_pos_by_mpidr(mpidr)" as an index to array "spm_core_context". 49 return &spm_core_context[plat_core_pos_by_mpidr(mpidr)]; 50 } 51 52 /******************************************************************************* 53 * SPM Core context on current CPU get helper. 54 ******************************************************************************/ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Sandeep Tripathy

Hi Soby, I realize using term 'PSCI API' in rfc tag is misleading like Achin mentioned in gerrit. Here I wanted to have a generic API to 'stop_other_cores' in secure world. The usage is platform firmware specific. Implementation of 'stop_other_cores' depends on a generic 'IPI' support (1). It leverages the existing EHF. So I feel it is not adding and complexity or overhead in normal execution path. 'stop_other_cores' API implementation depends on some psci private functions to traverse the pd nodes and extract MPIDRs for target pe list. That was the reason to put the function within psci lib. So there are two things. 1- Does this idea of 'stop_other_core' api qualify to be generic 2- Does a generic IPI layer make sense Thanks Sandeep > -----Original Message----- > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > Sent: Thursday, August 20, 2020 8:54 PM > To: Sandeep Tripathy > Cc: tf-a(a)lists.trustedfirmware.org > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > Hi Sandeep, > Just to understand better, if there is a secure side panic/watchdog > interrupt, > then the secure side is already able to do such an intervention without > the > availability of a PSCI API to the NS side. > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate > actions. From my reading, the PSCI specification doesn't prevent firmware > implementation of the reset and off API's from doing the kind of > implementation as per your proposal. I intend to do 'stop_other_cores' in platform extension of 'plat_system_resetx()', secure side watchdog expiry/ plat_panic_handler(). > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandeep > > Tripathy via TF-A > > Sent: 19 August 2020 16:42 > > To: tf-a(a)lists.trustedfirmware.org > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > Hi, > > I am proposing to have a generic api in psci lib which can be used to > force > > power down all other cores from any initiating core analogous to > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 > > software. > > > > Platforms may use this api in case of secure side panic, secure watchdog > > interrupt handling or if required in certain types of warm resets. The > > usage > is > > platform dependent. > > > > This depends on a generic implementation of secure IPI (1) which uses > > EHF > to > > handle IPI at platform defined priority. We probably require more types > > of > > secure IPIs. > > > > Please review the series > > Ref: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c > > index > > 141d69e..011aaa6 100644 > > --- a/lib/psci/psci_system_off.c > > +++ b/lib/psci/psci_system_off.c > > @@ -10,10 +10,44 @@ > > #include <arch_helpers.h> > > #include <common/debug.h> > > #include <drivers/console.h> > > +#include <drivers/delay_timer.h> > > #include <plat/common/platform.h> > > > > #include "psci_private.h" > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > + int idx, this_cpu_idx, cnt; > > + > > + this_cpu_idx = plat_my_core_pos(); > > + > > + /* Raise G0 IPI cpustop to all cores but self */ > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > + if ((idx != this_cpu_idx) && > > + (psci_get_aff_info_state_by_idx(idx) == > > AFF_STATE_ON)) { > > + > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > + } > > + } > > + > > + /* Wait for others cores to shutdown */ > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) > { > > + if (psci_is_last_on_cpu()) > > + break; > > + mdelay(1); > > + } > > + > > + if (!psci_is_last_on_cpu()) { > > + WARN("Failed to stop all cores!\n"); > > + psci_print_power_domain_map(); > > + } > > +} > > +#endif > > + > > > > (1) > > RFC: ipi: add ipi feature > > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/5323/1 > > > > Thanks > > Sandeep > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

2
1
0 0

Re: [TF-A] [RFC] psci: api to power down all cores

by Soby Mathew

Hi Sandeep, Just to understand better, if there is a secure side panic/watchdog interrupt, then the secure side is already able to do such an intervention without the availability of a PSCI API to the NS side. In case the NS world has crashed, then PSCI_SYSTEM_RESET and PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate actions. From my reading, the PSCI specification doesn't prevent firmware implementation of the reset and off API's from doing the kind of implementation as per your proposal. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 19 August 2020 16:42 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] [RFC] psci: api to power down all cores > > Hi, > I am proposing to have a generic api in psci lib which can be used to force > power down all other cores from any initiating core analogous to > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 software. > > Platforms may use this api in case of secure side panic, secure watchdog > interrupt handling or if required in certain types of warm resets. The usage is > platform dependent. > > This depends on a generic implementation of secure IPI (1) which uses EHF to > handle IPI at platform defined priority. We probably require more types of > secure IPIs. > > Please review the series > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c index > 141d69e..011aaa6 100644 > --- a/lib/psci/psci_system_off.c > +++ b/lib/psci/psci_system_off.c > @@ -10,10 +10,44 @@ > #include <arch_helpers.h> > #include <common/debug.h> > #include <drivers/console.h> > +#include <drivers/delay_timer.h> > #include <plat/common/platform.h> > > #include "psci_private.h" > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > + int idx, this_cpu_idx, cnt; > + > + this_cpu_idx = plat_my_core_pos(); > + > + /* Raise G0 IPI cpustop to all cores but self */ > + for (idx = 0; idx < psci_plat_core_count; idx++) { > + if ((idx != this_cpu_idx) && > + (psci_get_aff_info_state_by_idx(idx) == AFF_STATE_ON)) { > + plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > + } > + } > + > + /* Wait for others cores to shutdown */ > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) { > + if (psci_is_last_on_cpu()) > + break; > + mdelay(1); > + } > + > + if (!psci_is_last_on_cpu()) { > + WARN("Failed to stop all cores!\n"); > + psci_print_power_domain_map(); > + } > +} > +#endif > + > > (1) > RFC: ipi: add ipi feature > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/1 > > Thanks > Sandeep > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

[RFC] psci: api to power down all cores

by Sandeep Tripathy

Hi, I am proposing to have a generic api in psci lib which can be used to force power down all other cores from any initiating core analogous to 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 software. Platforms may use this api in case of secure side panic, secure watchdog interrupt handling or if required in certain types of warm resets. The usage is platform dependent. This depends on a generic implementation of secure IPI (1) which uses EHF to handle IPI at platform defined priority. We probably require more types of secure IPIs. Please review the series Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c index 141d69e..011aaa6 100644 --- a/lib/psci/psci_system_off.c +++ b/lib/psci/psci_system_off.c @@ -10,10 +10,44 @@ #include <arch_helpers.h> #include <common/debug.h> #include <drivers/console.h> +#include <drivers/delay_timer.h> #include <plat/common/platform.h> #include "psci_private.h" +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 +#endif + +#if IMAGE_BL31 +void psci_stop_other_cores(void) +{ +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 +#endif + +#if IMAGE_BL31 +void psci_stop_other_cores(void) +{ + int idx, this_cpu_idx, cnt; + + this_cpu_idx = plat_my_core_pos(); + + /* Raise G0 IPI cpustop to all cores but self */ + for (idx = 0; idx < psci_plat_core_count; idx++) { + if ((idx != this_cpu_idx) && + (psci_get_aff_info_state_by_idx(idx) == AFF_STATE_ON)) { + plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); + } + } + + /* Wait for others cores to shutdown */ + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) { + if (psci_is_last_on_cpu()) + break; + mdelay(1); + } + + if (!psci_is_last_on_cpu()) { + WARN("Failed to stop all cores!\n"); + psci_print_power_domain_map(); + } +} +#endif + (1) RFC: ipi: add ipi feature Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/1 Thanks Sandeep

4 years, 9 months

1
0
0 0

Re: [TF-A] [Hafnium] Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi Raghu, Thank you very much for your feedback! It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? Yes, your understanding is correct. The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. I agree with you that the approach you described above would make the whole process a bit cleaner. One way this could be done is by passing the *.pre.dts files (generated after the initial processing from dtc) to the script that are part of the patch. Last time I worked on this, I added the possibility to generate the nodes structure to an already existing dts file. Thus, expanding the previous configuration with the values of the new nodes. However, this work needs further testing. Alternatively, the python package I am using in the script can parse and generate dtb instead of dts. I was thinking to add the option to the dts_gen.py script (maybe rename it as well) to operate over the dtb format. So, making sure that "in-place" changes are working , and adding the option to operate over dtb files should allow for the cleaner approach that you referred. As is and making the referred changes, most of the script's logic should be preserved, so I don't think there will be a lot of changes to the current implementation, which is good. Please let me know if I was not very clear, or if you have any other comments. Also thanks @Gyorgy Szing<mailto:Gyorgy.Szing@arm.com> for the feedback on the current state of the patch, I appreciate it. Let me know if anyone has questions, or any other comments to the scripts and/or current discussion. I will notify once the work progresses. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, August 7, 2020 5:54 PM To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

1
0
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 13 Aug 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: " Next TF-A Tech Forum is now scheduled for 26th August" 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 13 Aug 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://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 at https://support.google.com/calendar/answer/37135#forwarding

4 years, 9 months

1
0
0 0

TF-A Tech Forum CANCELLED @ Thr 13th August 2020 16:00-1700 BST

by Joanna Farley

Apologies everyone, I need to cancel this week’s TF-A Tech Forum as presenters for our next subjects are all on vacation or have yet to complete preparation of the necessary material. As a reminder we have a scheduling page https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ If anybody has subjects they are willing to present please reach out to me so we can find you an appropriate slot. Next TF-A Tech Forum is now scheduled for 26th August. Thanks Joanna

4 years, 9 months

1
0
0 0

Missing properties from cactus dts

by Varun Wadekar

Hello Olivier, Hope you are doing well. As you already know, we are trying to test FF-A, using Cactus, on pre-8.4 Tegra platforms. While doing so, we saw that cactus.dts was missing the following properties 1. maj_ver 2. min_ver 3. spmc_id plat_spm_core_manifest_load() expects these values in the core manifest file. i.e. cactus.dts. What would be the right path forward? Do we add these fields to the dts file? Or modify plat_spmd_manifest.c file? -Varun

4 years, 9 months

2
1
0 0

Re: [TF-A] Fw: Automate generation of Partition's specific configuration

by raghu.ncstate＠icloud.com

Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

1
0
0 0

[Request for review] Tegra platform changes

by Varun Wadekar

Hi Team, Can you please help review the changes [1] posted for Tegra platforms? These were pushed on 07/09 and I would like to make progress. Several other changes are blocked on this merge. Thanks, Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-07092020%22+…

4 years, 9 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361221: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 9 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Varun Wadekar

Hi, I guess I'm late for the party. But I have some questions. Looking at the initial email from Andrew, these two points stood out. --8<-- 1. Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. 2. TF-A will also have to be compatible with whatever workaround the EL2 software is using -->8-- Some questions about the unwanted dependency that this fix in TF-A creates. 1. Does KVM team always announce all the dependencies, along with their version numbers, that consumers should use? 2. With the fix in TF-A, are we forcing consumers to upgrade their TF-A blobs? Is this normal practice for consumers? 3. How do we plan to make the upgrade from TF-A side easier? Runtime detection of the feature (similar to the Spectre and Meltdown fixes) comes to mind. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Badarkhe via TF-A Sent: Thursday, July 30, 2020 10:48 PM To: tf-a(a)lists.trustedfirmware.org Cc: Will Deacon <willdeacon(a)google.com>; android-kvm(a)google.com; Marc Zyngier <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; Andrew Scull <ascull(a)google.com> Subject: Re: [TF-A] Erroneous speculative AT workaround External email: Use caution opening links or attachments Hi All As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open… These changes are currently under review. Thanks Manish Badarkhe On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > -----Original Message----- > From: Will Deacon <willdeacon(a)google.com> > Sent: 02 July 2020 15:47 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Andrew Scull <ascull(a)google.com>; Raghu K > <raghu.ncstate(a)icloud.com>; android-kvm(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere? Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated. Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly. Best Regards Soby Mathew > > Will -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

3
4
0 0

Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

1
0
0 0

Re: [TF-A] cactus and ivy on Tegra194

by Varun Wadekar

Hello Olivier, What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194 External email: Use caution opening links or attachments Hi, >> [OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment). [VW] I think it makes sense to keep cactus alive for pre-8.4 in tfa-tests repo. Using cactus would help us verify the initial boot expectations without having to port OP-TEE. I guess, successful handling of the FFA_VERSION call would be a good milestone for us. >> There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story. @Matteo may provide pointers? [VW] Good to know. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Tuesday, July 28, 2020 9:09 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: cactus and ivy on Tegra194 External email: Use caution opening links or attachments Hi Varun, See inline [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 27 July 2020 18:28 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194 Hi Olivier, Thanks for your response. Looks like Ivy is still getting built in the tree and the fixes I have made are for the UART console driver - so can still be pushed upstream. [OD] It is built although it has no usage in any of TF-A CI test AFAIK. It is still using the former SPCI Alpha SPRT which is now deprecated. I should have mentioned earlier - Tegra194 is based off Arm v8.2. So, we cannot run Hafnium on that platform. The intent is to test the SPMD/SPMC and FF-A interface, before Hafnium comes along. So, the question is, can you please post instructions for pre-8.4 platforms? [OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment). There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story. @Matteo may provide pointers? The dual-cactus use case is interesting. Can we try that on pre-8.4 platforms too? [OD] Cactus was re-purposed only for being used as S-EL1 partitions on top of SPMC/Hafnium. So unfortunately no, you cannot immediately re-use this without S-EL2. There is no plan to let Cactus run at secure physical FF-A instance, although maybe that may work with some adaptation. The dual cactus case, is about instantiating two SPs (or VMs...) on top of Hafnium in the secure side. This is eventually the same binary payload run in two different sandboxes (differentiated by their FF-A id), to which direct message request can be emitted from TFTF to the corresponding FF-A id. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Monday, July 27, 2020 1:36 AM To: tf-a(a)lists.trustedfirmware.org; Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: cactus and ivy on Tegra194 External email: Use caution opening links or attachments Hi Varun, Please consider Ivy (and Quark) payloads are remnant from older SPCI specs and must be considered deprecated. We did not clean this in deep to remove the related test code but AFAIK it's just not used anywhere in the test suites (although it may still be built). We may have a plan to upgrade this later when working on S-EL0 partitions on top of Hafnium, but that's not an immediate priority. Considering Cactus, that's the bare-metal S-EL1 payload you can use in place of a real TOS on top of Hafnium. The intent is to test FF-A ABIs unitarily at secure virtual FF-A instance. TFTF at EL2 exercises the ABI at non-secure physical FF-A instance to communicate with the secure endpoint. See below the build commands we use for FVP. Hopefully this should help porting to your platform. Notice it needs as well building the SPMC (aka Hafnium in the secure side), which only supports FVP at this moment (and Rpi, qemu...) It's not described here but I can guide you through this as well. I think you can just use a dummy BL32 payload for now, at least to test the build/integration. If TFTF and TF-A reside in the same top level dir: TFTF: this builds TFTF and cactus secure partitions make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp TESTS=spm -j8 TF-A: this uses TFTF, and assembles two cactus secure partitions within the FIP make \ CROSS_COMPILE=aarch64-none-elf- \ SPD=spmd \ CTX_INCLUDE_EL2_REGS=1 \ ARM_ARCH_MINOR=4 \ BL33=../tf-a-tests/build/fvp/debug/tftf.bin \ BL32=<path-to-secure-hafnium-bin>/hafnium.bin \ SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \ PLAT=fvp \ all fip The tool last FIP tool entries are the two cactus instances: B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x47DA3, size=0xC168, cmdline="--blob" D1582309-F023-47B9-827C-4464F5578FC8: offset=0x53F0B, size=0xC168, cmdline="--blob" Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 July 2020 06:46 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] cactus and ivy on Tegra194 Hello, In order to test the SPM dispatcher from TF-A, we plan to enable 'cactus' and 'ivy' on Tegra194 platforms. I was able to muscle my way through all the compilation issues, but the final payload generation part is not that clear. Can someone please help me with the steps to generate the final FIP package with all the payloads - TF-A, Cactus, Ivy? Thanks. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

2
7
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Alexei Fedorov

I've created https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5153 which should fix the issue. Please review and test. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Alexei Fedorov via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 31 July 2020 10:22 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Hi, Could you replace .word platform_normal_stacks with .quad platform_normal_stacks in plat\common\aarch64\platform_mp_stack.S and check if it fixes the issue? Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: 30 July 2020 23:55 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE +tf-a mailing list. Merging Lauren’s email. Hi Lauren, What command did you use to build TSP? I used the same command line from my original email and added SPD=tspd and I was able to get it to compile with Alexei’s fix. Thanks Raghu ________________________________ Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". Any suggestions? Thanks, Lauren From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Thursday, July 30, 2020 9:15 AM To: 'Alexei Fedorov' <Alexei.Fedorov(a)arm.com>; 'Olivier Deprez' <Olivier.Deprez(a)arm.com> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks I’ll try with GCC 11.0. What happens when you run a build without platform_normal_stacks? Does it even boot for you or does it crash in linux?? Trying to understand how you figured this was an issue and what prompted you to fix this by adding the adrp/.word. -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 9:02 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Yes. I'm using ENABLE_PIE=1, but the same behaviour will be observed with ENABLE_PIE=0 (except that the linker error won't be reported). I'm isning GCC 11.0.0. Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 16:50 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks. Are you using ENABLE_PIE=1? I’m using ENABLE_PIE=1 and I don’t see it in bl31.dump file with or without the “.word platform_normal_stacks” statement. However, when I do run FVP to linux without the statement, I see secondary a crash in EL3 with unhandled exception. So it is definitely required. Just trying to pin point what exactly is causing the crash. Thanks Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 8:43 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE With "platform_normal_stacks": bl31.dump 0000000004015280 l stacks 0000000000000000 platform_normal_stacks bl31.map: stacks 0x0000000004015280 0x4000 *(tzfw_normal_stacks) tzfw_normal_stacks 0x0000000004015280 0x4000 ./build/fvp/debug/bl31/platform_mp_stack.o 0x0000000004019280 __STACKS_END__ = . Without: platform_normal_stacks is missing from bl31.dump, bl31.map: stacks 0x0000000004015270 0x2d90 0x0000000004015270 __STACKS_START__ = . *(tzfw_normal_stacks) 0x0000000004018000 __STACKS_END__ = . Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 15:58 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Makes sense. Thanks. I just tried both debug and release builds, but I don’t see it being _removed_ by the linker. In either case I don’t see symbol information for platform_normal_stacks and only see symbol information for __STACK_START__. So what exactly are you referring to when the linker removes “declare_stack …” ? Also what build configuration? -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 7:43 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Having platform_normal_stacks referenced prevents linker from removal of declare_stack platform_normal_stacks, tzfw_normal_stacks, \ PLATFORM_STACK_SIZE, PLATFORM_CORE_COUNT, \ CACHE_WRITEBACK_GRANULE Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 15:31 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks Olivier, Alexei. >> Is it a copy/paste typo? [RK]Yes. >> Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks [RK]Sure. I can do that. But why does “.word platform_normal_stacks” exist there in the first place? Not sure I understand that line’s purpose. What does replacing it with adrp x0, platform_normal_stacks do? The instruction is after a ret and looks like it will not be executed. I am using aarch64-non-elf- as the toolchain. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Alexei Fedorov via TF-A Sent: Thursday, July 30, 2020 6:58 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks Regards. Alexei. ________________________________ From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Sent: 30 July 2020 14:17 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Hi Raghu, On the toolchain question you would normally use CROSS_COMPILE=aarch64-none-elf- as recommended here: https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… However this does not seem to be the root cause of the problem you report. I reproduce the build issue, however it's not yet clear to me if this platform_normal_stacks variable should be rather placed in a specific section (.data?), rather than embedded in the code. Tbc. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Alexei Fedorov via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 30 July 2020 14:53 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error “./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I’m using? See gcc version below. Command line I’m using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu 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. 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. 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.

4 years, 9 months

3
6
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by raghu.ncstate＠icloud.com

+tf-a mailing list. Merging Lauren's email. Hi Lauren, What command did you use to build TSP? I used the same command line from my original email and added SPD=tspd and I was able to get it to compile with Alexei's fix. Thanks Raghu _____ Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". Any suggestions? Thanks, Lauren From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Thursday, July 30, 2020 9:15 AM To: 'Alexei Fedorov' <Alexei.Fedorov(a)arm.com>; 'Olivier Deprez' <Olivier.Deprez(a)arm.com> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks I'll try with GCC 11.0. What happens when you run a build without platform_normal_stacks? Does it even boot for you or does it crash in linux?? Trying to understand how you figured this was an issue and what prompted you to fix this by adding the adrp/.word. -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 9:02 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Yes. I'm using ENABLE_PIE=1, but the same behaviour will be observed with ENABLE_PIE=0 (except that the linker error won't be reported). I'm isning GCC 11.0.0. Regards. Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 16:50 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks. Are you using ENABLE_PIE=1? I'm using ENABLE_PIE=1 and I don't see it in bl31.dump file with or without the ".word platform_normal_stacks" statement. However, when I do run FVP to linux without the statement, I see secondary a crash in EL3 with unhandled exception. So it is definitely required. Just trying to pin point what exactly is causing the crash. Thanks Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 8:43 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE With "platform_normal_stacks": bl31.dump 0000000004015280 l stacks 0000000000000000 platform_normal_stacks bl31.map: stacks 0x0000000004015280 0x4000 *(tzfw_normal_stacks) tzfw_normal_stacks 0x0000000004015280 0x4000 ./build/fvp/debug/bl31/platform_mp_stack.o 0x0000000004019280 __STACKS_END__ = . Without: platform_normal_stacks is missing from bl31.dump, bl31.map: stacks 0x0000000004015270 0x2d90 0x0000000004015270 __STACKS_START__ = . *(tzfw_normal_stacks) 0x0000000004018000 __STACKS_END__ = . Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 15:58 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Makes sense. Thanks. I just tried both debug and release builds, but I don't see it being _removed_ by the linker. In either case I don't see symbol information for platform_normal_stacks and only see symbol information for __STACK_START__. So what exactly are you referring to when the linker removes "declare_stack ." ? Also what build configuration? -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 7:43 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Having platform_normal_stacks referenced prevents linker from removal of declare_stack platform_normal_stacks, tzfw_normal_stacks, \ PLATFORM_STACK_SIZE, PLATFORM_CORE_COUNT, \ CACHE_WRITEBACK_GRANULE Regards. Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 15:31 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks Olivier, Alexei. >> Is it a copy/paste typo? [RK]Yes. >> Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks [RK]Sure. I can do that. But why does ".word platform_normal_stacks" exist there in the first place? Not sure I understand that line's purpose. What does replacing it with adrp x0, platform_normal_stacks do? The instruction is after a ret and looks like it will not be executed. I am using aarch64-non-elf- as the toolchain. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org> > On Behalf Of Alexei Fedorov via TF-A Sent: Thursday, July 30, 2020 6:58 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> >; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks Regards. Alexei. _____ From: Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Sent: 30 July 2020 14:17 To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> >; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Hi Raghu, On the toolchain question you would normally use CROSS_COMPILE=aarch64-none-elf- as recommended here: <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial- build.html#performing-an-initial-build> https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-b uild.html#performing-an-initial-build However this does not seem to be the root cause of the problem you report. I reproduce the build issue, however it's not yet clear to me if this platform_normal_stacks variable should be rather placed in a specific section (.data?), rather than embedded in the code. Tbc. Regards, Olivier. ________________________________________ From: TF-A < <mailto:tf-a-bounces@lists.trustedfirmware.org> tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Alexei Fedorov via TF-A < <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 14:53 To: <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A < <mailto:tf-a-bounces@lists.trustedfirmware.org> tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A < <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org < <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I'm using? See gcc version below. Command line I'm using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu 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. 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. 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.

4 years, 9 months

2
1
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Manish Badarkhe

Hi All As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open… These changes are currently under review. Thanks Manish Badarkhe On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > -----Original Message----- > From: Will Deacon <willdeacon(a)google.com> > Sent: 02 July 2020 15:47 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Andrew Scull <ascull(a)google.com>; Raghu K > <raghu.ncstate(a)icloud.com>; android-kvm(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere? Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated. Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly. Best Regards Soby Mathew > > Will -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A