- TF-A - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 7th May 2020 17:00-1800 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 7th May 2020 17:00 - 18: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. This meeting will be chaired by Bipin Ravi. Agenda: * Overview of a new TF-A Build System based on Cmake by Javier Almansa Sobrino * Optional TF-A Mailing List Topic Discussions Thanks Joanna

6 years

1
0
0 0

Re: [TF-A] Need input on Errata implementation

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu > Krishnamurthy via TF-A > Sent: 30 April 2020 02:33 > To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] Need input on Errata implementation > > Hi Manish, > > Really appreciate you for taking time to respond to my concerns/questions. > > What about this situation? NS-EL2 makes an SMC call to EL3 to get some basic > information like GET_SOC_INFORMATION. This is a simple SMC and there is no > call to context save or context restore. During the SMC call, if there is a > speculative AT instruction on a lower EL(say NS-EL2), there could be a bad > cached translation. Do you not need to apply the errata in this situation ? If > not, why? > > >>We can't simply apply this errata on reset and just leave the system. > > [RK]Totally agree. See CPU_E_HANDLER_FUNC. It is not necessary that > cpu_ops are only called during reset and power down. > CPU_E_HANDLER_FUNC is called at runtime due EA's. > > >>We thought of taking different approach for this errata > implementation >>where anybody disable this workaround using macro as > this errata is >>applicable for most of the CPUs (by default enabled) and can't > be >>placed in cpu_ops. > > [RK]This is a poor approach in my view. Most CPU's is not all CPU's. The reason > the errata framework exists is to apply CPU specific erratas by checking for > them dynamically. Different stepping's of the same CPU's may or may not have > the errata and typically you check the MIDR to know if the errata applies or > not. Linux does not apply the errata to all CPU's since "most" CPU's have the > issue. They check for its existence at runtime and only then apply it. TF-A > should not hold itself to a lower standard. Hi Raghu I guess this depends on what the errata workaround involves. Since this workaround applies bit setting on an out of context register, it was not expected to affect the EL3 execution performance (or the lower level EL because the bits are restored on return). Also it was thought that the act of searching through the list of compiled CPUs and checking if the workaround is applicable might be more detrimental than the unilateral application of the workaround for this case (assuming no extra barriers are added since the code path it is inserted in have them already later in the sequence). But I agree it is more elegant to have this coupled into CPU_OPS framework. I think Manish has some ideas for this. Best Regards Soby Mathew > > -Raghu > > On 4/29/20 1:35 AM, Manish Badarkhe wrote: > > Hi Raghu > > > > Just to add/correct one more thing from my previous emails that this errata > workaround proposed is > > applied to both normal and secure world switches to EL3. > > > > Thanks > > Manish Badarkhe > > > > On 29/04/2020, 12:25, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a- > bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> > wrote: > > > > Hi Raghu > > > > On 29/04/2020, 02:00, "Raghu K" <raghu.ncstate(a)icloud.com> wrote: > > > > Hi Manish, > > > > Thanks. > > > > >> we don’t have any AT instances in minimum execution window after > context switching from S-EL(1/2) > > >> to EL3 and before updating TCR register. > > > > 1) What is the minimum execution window? Does that not change based > on micro-architecture? > > Not sure about exact minimum execution window. IMO, it really depend > upon when "context_save" gets called after > > entering into EL3 from S-EL1/2. It may changed upon micro-architecture. > Need some experts comment here. > > > > 2) Do we know that the "execution window" is exactly the same for all > the CPU's this errata applies to? > > It may be but we should not worry on that if we don’t have any AT > instruction execution in that window. > > > > Also, it appears we are only talking about switching from S-EL1/2 to EL3. > The same issue can happen when you go from NS-EL1/EL2 to EL3 as well. There > also seems to be an assumption in the patch you submitted that this errata > happens only during a so called context-switch. From my reading, the cortex- > Ax errata notices don't limit the errata to occur only during "context-switches" > in the "conditions" section and can occur while executing ANY code, although > the work around section does muddy the waters a bit. > > > > In Linux, at NS-EL2 this workaround is already in place. Hence we just > thought of considering cases from Secure EL side to put this workaround. > > Yes, errata should not limit to particular conditional section but this > particular errata is not straight-forward like another errata placed in the code > currently. We can't simply apply this errata on reset and just leave the system. > > > > Back to problem, AT instruction speculative execution using out-of- > context regime that results in page table walk and generate the incorrect > > translation which are cached in TLB. To avoid this issue we thought of > disabling PTW for that particular EL. > > for e.g. If AT instruction execution for EL1 present in EL3 then we have to > make sure speculative behaviour of this AT should not result in incorrect > translation cached in TLB. If system is always in EL3 (if we loop-in in EL3 always > without going back and forth to/from lower EL) then in that case > > there is no need of this workaround. > > Hence we thought to put this workaround over boundary context of > context switches. When "context save" (close to EL3 entry) happened we > meticulously save all EL system registers (S-EL1/S-EL2) with PTW disabled and > continue EL3 execution with PTW disabled ensuring we should not cache any > incorrect translation for (S-EL1/S-EL2) and during "context restore" (i.e. close > to EL3 exit) again we disabled PTW, restore all system registers for EL (S-EL1/S- > EL2) except TCR and then restore TCR. > > > > 3) Has there been any work done to actually reproduce this issue and > also to see that this actually fixes the issue? > > No this issue is hard to reproduce. > > > > 4) Has the CPU errata framework(cpu_ops etc.) been considered to > possibly implement the errata? Sprinkling erratas through common framework > code does not seem like a good idea. > > We thought of taking different approach for this errata implementation > where anybody disable this workaround using macro as this errata is > applicable for most of the CPUs (by default enabled) and can't be placed in > cpu_ops. > > > > Thanks > > Raghu > > > > Thanks > > Manish Badarkhe > > > > On 4/28/20 1:44 AM, Manish Badarkhe wrote: > > > Hi Raghu > > > > > > Please see my replies inline. > > > > > > Regards > > > Manish Badarkhe > > > > > > On 28/04/2020, 11:29, "Raghu Krishnamurthy" > <raghu.ncstate(a)icloud.com> wrote: > > > > > > Hi Manish, > > > > > > Understood. > > > > > > >>Hence before entering in EL3, we ensured that PTW is disabled > (at > > > context save) > > > > > > The context save and restore functions are executed in EL3. So how > are > > > you disabling PTW before entering EL3 ? > > > > > > Yes, I put it wrongly. We thought "context_save/restore" is best place > to disable PTW without much affecting the > > > code because we don’t have any AT instances in minimum execution > window after context switching from S-EL(1/2) > > > to EL3 and before updating TCR register. > > > > > > -Raghu > > > > > > Thanks > > > Manish Badarkhe > > > > > > On 4/27/20 10:53 PM, Manish Badarkhe wrote: > > > > Hi Raghu > > > > > > > > This workaround is specifically need for speculative AT instruction > behaviour in out of context regime. > > > > That means executing AT instruction for lower ELs (S-EL1/S-EL2) in > higher EL i.e. EL3. > > > > > > > > Behaviour of AT instruction is unaltered when it get executed in > same regime (when AT instruction executed for same EL > > > > where it is executing) and there is no possibility to execute AT > instruction for higher EL in lower EL. > > > > > > > > Hence before entering in EL3, we ensured that PTW is disabled (at > context save) and restore PTW back during > > > > exit of EL3. (at context restore). > > > > > > > > Thanks > > > > Manish Badarkhe > > > > > > > > On 28/04/2020, 01:23, "Raghu K" <raghu.ncstate(a)icloud.com> > wrote: > > > > > > > > Hi Manish, > > > > > > > > >>Hence proposed solution will work as it is > > > > > > > > [RK]If you are sure go ahead. I'm not convinced, but that may > be because > > > > i don't understand the errata fully/correctly. > > > > > > > > >>This workaround is very specific during context switching > > > > > > > > [RK] Context switching has many meanings depending on the > context(OS, > > > > hypervisor, TF-A world switch etc). The errata document i saw > does not > > > > elaborate on this. Perhaps clarifying this will help understand > why the > > > > solution you proposed will work. > > > > > > > > The solution below in points 2 and 3 have the same problem on > entry and > > > > exit, mentioned in my first email. Before you call > > > > el1_sysregs_context_save, an AT instruction could have > speculatively > > > > executed through speculation of branches that occur BEFORE > you call this > > > > function, when TCR still has the enable bit set. The fact that you > don't > > > > have an AT instruction in the context save routine or any > routine for > > > > that matter, does not guarantee that the hardware did not > speculate > > > > through some other means to reach an AT instruction. The > same applies to > > > > the context_restore routines. There is no guarantee right after > you > > > > finish the restore routing(and hence TCR has the enable bit set), > that > > > > the CPU cannot speculate to an AT instruction. > > > > So i'm not clear how you can say for certain that there was no > > > > speculative AT instruction with the proposal below. > > > > > > > > Thanks > > > > Raghu > > > > > > > > On 4/27/20 10:08 AM, Manish Badarkhe wrote: > > > > > Hi All, > > > > > > > > > > Just update/correct details. > > > > > > > > > > Thanks > > > > > Manish Badarkhe > > > > > > > > > > On 27/04/2020, 22:13, "TF-A on behalf of Manish Badarkhe > via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf- > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > Hi Raghu > > > > > > > > > > Please ignore my answer on question 2. > > > > > > > > > > With internal discussion came to below conclusion: > > > > > 1. This workaround is very specific during context > switching. > > > > > 2 . If you check in context save routine > (el1_sysregs_context_save or el2_sysregs_context_save), > > > > > As per proposed solution, First step performed is to > disable page table walk and we don’t have > > > > > any AT instruction execution in context save routine. > > > > > This ensures that there will be no possibility of > speculative AT instruction execution without TCR update. > > > > > 3. If you check in context restore routine > (el1_sysregs_context_restore or el2_sysregs_context_restore), > > > > > As per proposed solution, first step performed is to > disable page table walk and we don’t have any > > > > > AT instruction execution in context restore routine. > > > > > This ensures that there will be no possibility of > speculative AT instruction execution without TCR update. > > > > > > > > > > Hence proposed solution will work as it is ensuring no > caching of translations in TLB while speculative AT instruction execution. > > > > > > > > > > Thanks > > > > > Manish Badarkhe > > > > > > > > > > On 27/04/2020, 13:38, "TF-A on behalf of Manish Badarkhe > via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf- > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > Hi Raghu > > > > > > > > > > Please see my answers inline > > > > > > > > > > On 25/04/2020, 06:38, "TF-A on behalf of Raghu K via TF- > A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf- > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > Hi Manish, > > > > > > > > > > Before I agree or disagree with the suggested fix, the > following would > > > > > be interesting to know/discuss. Please feel free to > correct me if i've > > > > > misunderstood something. > > > > > > > > > > 1) Are "speculative" AT instructions subject to TCR_ELx > control bits for > > > > > all the listed CPU's? I imagine the answer is yes but > would be good to > > > > > get confirmation. I could not find any evidence in the > instruction > > > > > description or psuedocode in the ARMv8 ARM. It is > possible to play many > > > > > tricks on speculative execution of instructions such as > skipping checks > > > > > and doing them only when the CPU knows the > instruction will be > > > > > committed. If this is the case, changing TCR_ELx bits > may not work. The > > > > > errata document is vague about how to fix it. > > > > > > > > > > The speculative AT instruction may behave as you > mentioned. We need more > > > > > opinion on this. > > > > > Proposed fix I mentioned by referring linux workaround > for the same errata. > > > > > Linux workaround is available in mainline kernel as > below: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > v5.7-rc3&id=bd227553ad5077f21ddb382dcd910ba46181805a > > > > > > > > > > 2) Assuming the answer to question 1 is yes, your > proposal may not work > > > > > as is. In the worst case, as soon as you enter EL3, the > very first thing > > > > > that may happen, before you ever operate/write to > TCR_ELx, is a > > > > > speculative AT instruction that caches a bad translation > in the TLB's. > > > > > The same thing can happen on the exit path. As soon as > you restore the > > > > > TCR_ELx register, the first thing that can happen is a > speculative AT > > > > > that caches a bad translation. However, the el3_exit > path does have DSB > > > > > before ERET, so we will not speculate to an AT > instruction if there are > > > > > no branches between the instruction that sets TCR_ELx > and the ERET. > > > > > Somewhere in between, it looks like we will need a > TLBI NSH to be > > > > > certain there are no bad translation cached. This > obviously has a > > > > > potential performance cost on the lower EL's. Every > entry into EL3 > > > > > flushes the TLB for lower EL's. > > > > > > > > > > Yes, this seems to be valid case during entry and exit path. > > > > > I am not quite sure in that case where we need to avoid > PTW. > > > > > Also "TLBI NSH" works but it may cause performance > issue. > > > > > Need some more opinion/thoughts on this. > > > > > > > > > > Just thinking, can sequence mentioned for context save > does not ensure that > > > > > PTW is disabled? > > > > > Something as below as last step in ELx(1/2) context save > (elaborated more): > > > > > > ·Save TCR register with PTW enable (EPD=0). (Just to > enable PTW during > > > > > > restore context). Do not operate TCR_EL1x register > here just save its value to restore. > > > > > > This ensures that during entry in EL3 there will be no > chance of PTW > > > > > >. while executing AT instruction. > > > > > > > > > > Thanks > > > > > > > > > > Raghu > > > > > > > > > > Thanks > > > > > Manish Badarkhe > > > > > > > > > > On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > > > > > > > > > > > Hi All > > > > > > > > > > > > We are trying to implement errata which is applicable > for below CPUs: > > > > > > > > > > > > <CPUs> : <Errata No.> > > > > > > > > > > > > Cortex-A53: 1530924 > > > > > > > > > > > > Cortex-A76: 1165522 > > > > > > Cortex-A72: 1319367 > > > > > > Cortex-A57: 1319537 > > > > > > Cortex-A55: 1530923 > > > > > > > > > > > > *Errata Description:* > > > > > > > > > > > > A speculative Address Translation (AT) instruction > translates using > > > > > > registers that are associated with an out-of-context > translation > > > > > > regime and caches the resulting translation in the TLB. > A subsequent > > > > > > translation request that is generated when the out- > of-context > > > > > > translation regime is current uses the previous cached > TLB entry > > > > > > producing an incorrect virtual to physical mapping. > > > > > > > > > > > > *Probable solution is to implement below fix in > context.S file:* > > > > > > > > > > > > *During ELx (1 or 2) context save:* > > > > > > > > > > > > ·Operate TCR_ELx(1/2) to disable page table walk by > operating EPD bits > > > > > > > > > > > > oThis will avoid any page table walk for S-EL1 or S-EL2. > This will > > > > > > help in avoiding caching of translations in TLB > > > > > > > > > > > > for S-EL1/S-EL2 in EL3. > > > > > > > > > > > > ·Save all system registers (which is already available) > except TCR > > > > > > > > > > > > ·Clear EPD bits of TCR and then save. (Just to enable > PTW during > > > > > > restore context). > > > > > > > > > > > > *During ELx (1 or 2) context restore:* > > > > > > > > > > > > * Operate TCR_ELx(1/2) to disable page table walk > by operating EPD bits > > > > > > * Restore all system registers (which are saved > during context save) > > > > > > except TCR register. > > > > > > * Restore TCR_ELx(1/2) register (which enable back > PTW). > > > > > > > > > > > > With above we ensured that there will be no page > table walk for S-EL1 > > > > > > and S-EL2 in EL3. > > > > > > > > > > > > is this proper other way to fix this problem? Need > some suggestion/use > > > > > > cases where and all we need this workaround in TF-A > code. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Manish Badarkhe > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > -- > > > > > TF-A mailing list > > > > > TF-A(a)lists.trustedfirmware.org > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > > > > 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. > > > > > -- > > > > > TF-A mailing list > > > > > TF-A(a)lists.trustedfirmware.org > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > > > > 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. > > > > > -- > > > > > TF-A mailing list > > > > > TF-A(a)lists.trustedfirmware.org > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > > > > 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. > > > > > > -- > > 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

6 years

3
6
0 0

Re: [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, I've received very little feedback on version 2 of the proposal, which hints that we are reaching an agreement. Thus, I plan to finalize the proposal this week. This can then become part of our development flow for all trustedfirmware.org projects. Thanks again for all the inputs! Regards, Sandrine Bailleux

6 years

1
0
0 0

Re: [TF-A] [RFC] isolation between runtime BL33 services and OS

by Achin Gupta

Hi Francois, On Mon, Apr 20, 2020 at 11:45:02AM +0000, François Ozog via TF-A wrote: > Hi, > > I am trying to identify a mechanism to enforce a form of two-way > isolation between BL33 runtime services in OS, for instance: > - a pair of 2MB areas that could be RO by one entity and RW by the other > - an execute only BL33 2MB area? Stupid Q! Are you referring to isolation between EFI runtime services and the OS? It is not clear what you mean by BL33 runtime services? cheers, Achin > > This is similar to hypervisor except it only deals with memory, no > vCPU, no GIC virtualization... > > Could EL3 or EL2 install protective mappings ? BL33 could ask either > EL2 hypervisor or SecureMonitor to actually install them. > > Cordially, > > FF > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years

2
5
0 0

Re: [TF-A] Need input on Errata implementation

by Manish Badarkhe

Hi Raghu Just to add/correct one more thing from my previous emails that this errata workaround proposed is applied to both normal and secure world switches to EL3. Thanks Manish Badarkhe On 29/04/2020, 12:25, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Raghu On 29/04/2020, 02:00, "Raghu K" <raghu.ncstate(a)icloud.com> wrote: Hi Manish, Thanks. >> we don’t have any AT instances in minimum execution window after context switching from S-EL(1/2) >> to EL3 and before updating TCR register. 1) What is the minimum execution window? Does that not change based on micro-architecture? Not sure about exact minimum execution window. IMO, it really depend upon when "context_save" gets called after entering into EL3 from S-EL1/2. It may changed upon micro-architecture. Need some experts comment here. 2) Do we know that the "execution window" is exactly the same for all the CPU's this errata applies to? It may be but we should not worry on that if we don’t have any AT instruction execution in that window. Also, it appears we are only talking about switching from S-EL1/2 to EL3. The same issue can happen when you go from NS-EL1/EL2 to EL3 as well. There also seems to be an assumption in the patch you submitted that this errata happens only during a so called context-switch. From my reading, the cortex-Ax errata notices don't limit the errata to occur only during "context-switches" in the "conditions" section and can occur while executing ANY code, although the work around section does muddy the waters a bit. In Linux, at NS-EL2 this workaround is already in place. Hence we just thought of considering cases from Secure EL side to put this workaround. Yes, errata should not limit to particular conditional section but this particular errata is not straight-forward like another errata placed in the code currently. We can't simply apply this errata on reset and just leave the system. Back to problem, AT instruction speculative execution using out-of-context regime that results in page table walk and generate the incorrect translation which are cached in TLB. To avoid this issue we thought of disabling PTW for that particular EL. for e.g. If AT instruction execution for EL1 present in EL3 then we have to make sure speculative behaviour of this AT should not result in incorrect translation cached in TLB. If system is always in EL3 (if we loop-in in EL3 always without going back and forth to/from lower EL) then in that case there is no need of this workaround. Hence we thought to put this workaround over boundary context of context switches. When "context save" (close to EL3 entry) happened we meticulously save all EL system registers (S-EL1/S-EL2) with PTW disabled and continue EL3 execution with PTW disabled ensuring we should not cache any incorrect translation for (S-EL1/S-EL2) and during "context restore" (i.e. close to EL3 exit) again we disabled PTW, restore all system registers for EL (S-EL1/S-EL2) except TCR and then restore TCR. 3) Has there been any work done to actually reproduce this issue and also to see that this actually fixes the issue? No this issue is hard to reproduce. 4) Has the CPU errata framework(cpu_ops etc.) been considered to possibly implement the errata? Sprinkling erratas through common framework code does not seem like a good idea. We thought of taking different approach for this errata implementation where anybody disable this workaround using macro as this errata is applicable for most of the CPUs (by default enabled) and can't be placed in cpu_ops. Thanks Raghu Thanks Manish Badarkhe On 4/28/20 1:44 AM, Manish Badarkhe wrote: > Hi Raghu > > Please see my replies inline. > > Regards > Manish Badarkhe > > On 28/04/2020, 11:29, "Raghu Krishnamurthy" <raghu.ncstate(a)icloud.com> wrote: > > Hi Manish, > > Understood. > > >>Hence before entering in EL3, we ensured that PTW is disabled (at > context save) > > The context save and restore functions are executed in EL3. So how are > you disabling PTW before entering EL3 ? > > Yes, I put it wrongly. We thought "context_save/restore" is best place to disable PTW without much affecting the > code because we don’t have any AT instances in minimum execution window after context switching from S-EL(1/2) > to EL3 and before updating TCR register. > > -Raghu > > Thanks > Manish Badarkhe > > On 4/27/20 10:53 PM, Manish Badarkhe wrote: > > Hi Raghu > > > > This workaround is specifically need for speculative AT instruction behaviour in out of context regime. > > That means executing AT instruction for lower ELs (S-EL1/S-EL2) in higher EL i.e. EL3. > > > > Behaviour of AT instruction is unaltered when it get executed in same regime (when AT instruction executed for same EL > > where it is executing) and there is no possibility to execute AT instruction for higher EL in lower EL. > > > > Hence before entering in EL3, we ensured that PTW is disabled (at context save) and restore PTW back during > > exit of EL3. (at context restore). > > > > Thanks > > Manish Badarkhe > > > > On 28/04/2020, 01:23, "Raghu K" <raghu.ncstate(a)icloud.com> wrote: > > > > Hi Manish, > > > > >>Hence proposed solution will work as it is > > > > [RK]If you are sure go ahead. I'm not convinced, but that may be because > > i don't understand the errata fully/correctly. > > > > >>This workaround is very specific during context switching > > > > [RK] Context switching has many meanings depending on the context(OS, > > hypervisor, TF-A world switch etc). The errata document i saw does not > > elaborate on this. Perhaps clarifying this will help understand why the > > solution you proposed will work. > > > > The solution below in points 2 and 3 have the same problem on entry and > > exit, mentioned in my first email. Before you call > > el1_sysregs_context_save, an AT instruction could have speculatively > > executed through speculation of branches that occur BEFORE you call this > > function, when TCR still has the enable bit set. The fact that you don't > > have an AT instruction in the context save routine or any routine for > > that matter, does not guarantee that the hardware did not speculate > > through some other means to reach an AT instruction. The same applies to > > the context_restore routines. There is no guarantee right after you > > finish the restore routing(and hence TCR has the enable bit set), that > > the CPU cannot speculate to an AT instruction. > > So i'm not clear how you can say for certain that there was no > > speculative AT instruction with the proposal below. > > > > Thanks > > Raghu > > > > On 4/27/20 10:08 AM, Manish Badarkhe wrote: > > > Hi All, > > > > > > Just update/correct details. > > > > > > Thanks > > > Manish Badarkhe > > > > > > On 27/04/2020, 22:13, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > > > > > Hi Raghu > > > > > > Please ignore my answer on question 2. > > > > > > With internal discussion came to below conclusion: > > > 1. This workaround is very specific during context switching. > > > 2 . If you check in context save routine (el1_sysregs_context_save or el2_sysregs_context_save), > > > As per proposed solution, First step performed is to disable page table walk and we don’t have > > > any AT instruction execution in context save routine. > > > This ensures that there will be no possibility of speculative AT instruction execution without TCR update. > > > 3. If you check in context restore routine (el1_sysregs_context_restore or el2_sysregs_context_restore), > > > As per proposed solution, first step performed is to disable page table walk and we don’t have any > > > AT instruction execution in context restore routine. > > > This ensures that there will be no possibility of speculative AT instruction execution without TCR update. > > > > > > Hence proposed solution will work as it is ensuring no caching of translations in TLB while speculative AT instruction execution. > > > > > > Thanks > > > Manish Badarkhe > > > > > > On 27/04/2020, 13:38, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > > > > > Hi Raghu > > > > > > Please see my answers inline > > > > > > On 25/04/2020, 06:38, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > > > > > Hi Manish, > > > > > > Before I agree or disagree with the suggested fix, the following would > > > be interesting to know/discuss. Please feel free to correct me if i've > > > misunderstood something. > > > > > > 1) Are "speculative" AT instructions subject to TCR_ELx control bits for > > > all the listed CPU's? I imagine the answer is yes but would be good to > > > get confirmation. I could not find any evidence in the instruction > > > description or psuedocode in the ARMv8 ARM. It is possible to play many > > > tricks on speculative execution of instructions such as skipping checks > > > and doing them only when the CPU knows the instruction will be > > > committed. If this is the case, changing TCR_ELx bits may not work. The > > > errata document is vague about how to fix it. > > > > > > The speculative AT instruction may behave as you mentioned. We need more > > > opinion on this. > > > Proposed fix I mentioned by referring linux workaround for the same errata. > > > Linux workaround is available in mainline kernel as below: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > > > > > 2) Assuming the answer to question 1 is yes, your proposal may not work > > > as is. In the worst case, as soon as you enter EL3, the very first thing > > > that may happen, before you ever operate/write to TCR_ELx, is a > > > speculative AT instruction that caches a bad translation in the TLB's. > > > The same thing can happen on the exit path. As soon as you restore the > > > TCR_ELx register, the first thing that can happen is a speculative AT > > > that caches a bad translation. However, the el3_exit path does have DSB > > > before ERET, so we will not speculate to an AT instruction if there are > > > no branches between the instruction that sets TCR_ELx and the ERET. > > > Somewhere in between, it looks like we will need a TLBI NSH to be > > > certain there are no bad translation cached. This obviously has a > > > potential performance cost on the lower EL's. Every entry into EL3 > > > flushes the TLB for lower EL's. > > > > > > Yes, this seems to be valid case during entry and exit path. > > > I am not quite sure in that case where we need to avoid PTW. > > > Also "TLBI NSH" works but it may cause performance issue. > > > Need some more opinion/thoughts on this. > > > > > > Just thinking, can sequence mentioned for context save does not ensure that > > > PTW is disabled? > > > Something as below as last step in ELx(1/2) context save (elaborated more): > > > > ·Save TCR register with PTW enable (EPD=0). (Just to enable PTW during > > > > restore context). Do not operate TCR_EL1x register here just save its value to restore. > > > > This ensures that during entry in EL3 there will be no chance of PTW > > > >. while executing AT instruction. > > > > > > Thanks > > > > > > Raghu > > > > > > Thanks > > > Manish Badarkhe > > > > > > On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > > > > > > > Hi All > > > > > > > > We are trying to implement errata which is applicable for below CPUs: > > > > > > > > <CPUs> : <Errata No.> > > > > > > > > Cortex-A53: 1530924 > > > > > > > > Cortex-A76: 1165522 > > > > Cortex-A72: 1319367 > > > > Cortex-A57: 1319537 > > > > Cortex-A55: 1530923 > > > > > > > > *Errata Description:* > > > > > > > > A speculative Address Translation (AT) instruction translates using > > > > registers that are associated with an out-of-context translation > > > > regime and caches the resulting translation in the TLB. A subsequent > > > > translation request that is generated when the out-of-context > > > > translation regime is current uses the previous cached TLB entry > > > > producing an incorrect virtual to physical mapping. > > > > > > > > *Probable solution is to implement below fix in context.S file:* > > > > > > > > *During ELx (1 or 2) context save:* > > > > > > > > ·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > > > > > > > oThis will avoid any page table walk for S-EL1 or S-EL2. This will > > > > help in avoiding caching of translations in TLB > > > > > > > > for S-EL1/S-EL2 in EL3. > > > > > > > > ·Save all system registers (which is already available) except TCR > > > > > > > > ·Clear EPD bits of TCR and then save. (Just to enable PTW during > > > > restore context). > > > > > > > > *During ELx (1 or 2) context restore:* > > > > > > > > * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > > > * Restore all system registers (which are saved during context save) > > > > except TCR register. > > > > * Restore TCR_ELx(1/2) register (which enable back PTW). > > > > > > > > With above we ensured that there will be no page table walk for S-EL1 > > > > and S-EL2 in EL3. > > > > > > > > is this proper other way to fix this problem? Need some suggestion/use > > > > cases where and all we need this workaround in TF-A code. > > > > > > > > Thanks > > > > > > > > Manish Badarkhe > > > > > > > > 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. > > > > > > > > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > 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. > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > 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. > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
1
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 18:00 to 19:00 on Thursday from Thu 7 May to Thu 30 Jul (CEST) (tf-a@lists.trustedfirmware.org)

by François Ozog

This event has been changed. 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: Every 2 weeks from 18:00 to 19:00 on Thursday from Thu 7 May to Thu 30 Jul Central European Time - Paris (changed) Where: Zoom Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY… 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

6 years

1
0
0 0

Re: [TF-A] 回复：RE: 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Olivier Deprez

Hi Bin Wu, Glad if this helped! Hi Thomas, Thanks for the heads up! Regards, Olivier. ________________________________________ From: 吴斌(郅隆) <zhilong.wb(a)alibaba-inc.com> Sent: 21 April 2020 13:52 To: Thomas Abraham; Olivier Deprez; TF-A Subject: 回复：RE: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Dear All, Thanks all your help again. Your professionalism and assistance impressed me. BRs， Bin Wu ------------------原始邮件 ------------------ 发件人:Thomas Abraham <thomas.abraham(a)arm.com> 发送时间:Tue Apr 21 19:38:38 2020 收件人:Olivier Deprez <Olivier.Deprez(a)arm.com>, TF-A <tf-a-bounces(a)lists.trustedfirmware.org>, 吴斌(郅隆) <zhilong.wb(a)alibaba-inc.com> 主题:RE: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hi, Looking into the mail chain below, this is probably being tested on RD-N1-Edge platform. There was regression noticed in the dmc620 ras error handling in the code pushed to Linaro for RD-N1-Edge platform. This will be fixed later today and patches will be merged into Linaro repos. It should then be accessible using the usual repo init/sync commands. Thanks, Thomas. > -----Original Message----- > From: TF-A On Behalf Of Olivier > Deprez via TF-A > Sent: Tuesday, April 21, 2020 4:45 PM > To: TF-A ; Raghu K via TF-A > a(a)lists.trustedfirmware.org>; 吴斌(郅隆) > Subject: Re: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - > 0xC4000061 and BL31 Crashed > > Hi Raghu, > > Yes you're right, we probably need few return code checks here and here. I > may submit a patch and verify it doesn't break anything else. > > Hi Bin Wu, > > I had noticed the following sequence originating from linux sdei driver init > down to TF-A: > > INFO: SDEI: Private events initialized on 81000100 > INFO: SDEI: Private events initialized on 81000200 > INFO: SDEI: Private events initialized on 81000300 > INFO: SDEI: Private events initialized on 81010000 > INFO: SDEI: Private events initialized on 81010100 > INFO: SDEI: Private events initialized on 81010200 > INFO: SDEI: Private events initialized on 81010300 > INFO: SDEI: > VER > INFO: SDEI: < VER:1000000000000 > INFO: SDEI: > P_RESET():81000000 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000200 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000300 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010000 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010100 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010200 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010300 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000100 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > S_RESET():81000100 > INFO: SDEI: < S_RESET:0 > INFO: SDEI: > UNMASK:81000000 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000100 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000200 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000300 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010000 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010100 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010200 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010300 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > INFO(n:804, 0) > INFO: SDEI: < INFO:0 > INFO: SDEI: > INFO(n:805, 0) > INFO: SDEI: < INFO:0 > > There is an Sdei Info request about events 804 and 805. > Although I don't see any register or enable event service call, so I wonder if > this demo code is missing something or expects that the platform > implements such event definition natively. > > This does not look like flows described in https://trustedfirmware- > a.readthedocs.io/en/latest/components/sdei.html > for regular SDEI usage or explicit dispatch of events. > > Maybe we should involve Linaro ppl on the expected init sequence and > dependency to TF-A (platform files). > > Regards, > Olivier. > > > ________________________________________ > From: TF-A on behalf of 吴斌(郅 > 隆) via TF-A > Sent: 21 April 2020 08:45 > To: TF-A; Raghu K via TF-A > Subject: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - > 0xC4000061 and BL31 Crashed > > Hi Olivier and All, > > Thank you so much for your help. It makes me understand the internals. > The next step, I need to check this event_num(804) register flow in kernel > side, am I right? > > > BRs， > Bin Wu > ------------------原始邮件 ------------------ > 发件人:TF-A > 发送时间:Tue Apr 21 09:51:49 2020 > 收件人:Raghu K via TF-A > 主题:Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and > BL31 Crashed > Nice debug! Apart from the issue you pointed out, there is also the > issue with not checking the return code. The ras handler should really > be checking or panic'ing if there is an unexpected error code from > spm_sp_call and sdei_dispatch_event. > > -Raghu > > On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > > Hi Bin Wu, > > > > Here's an early observation. On receiving the RAS fiq interrupt the > following occurs: > > > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call > (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > > > se = get_event_entry(map); > > if (!can_sdei_state_trans(se, DO_DISPATCH)) > > return -1; > > > > p *map > > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = > 0}} > > p *se > > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > > > sdei_dispatch_event exits in error at this stage, this does not seem a > correct behavior. > > The SDEI handler is not called in NS world and context remains unchanged. > > The interrupt handler blindly returns to S-EL1 SP context at same location > where it last exited. > > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry > fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > > SP then exits but the EL3 context has not been setup for SP entry leading > to crash. > > > > IMO there is an issue around mapping SDEI event number to RAS interrupt > number leading to sdei_dispatch_event exiting early. > > > > Regards, > > Olivier. > > > > > > ________________________________________ > > From: TF-A on behalf of Matteo Carlini via TF-A > > Sent: 14 April 2020 10:41 > > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak > Pandey > > Cc: nd > > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 > and BL31 Crashed > > > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team > platforms releases. They might be able to help. > > > > Thanks > > Matteo > > > > From: TF-A On Behalf Of ??(??) via TF-A > > Sent: 14 April 2020 06:47 > > To: TF-A ; Raghu Krishnamurthy via TF-A > > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 > and BL31 Crashed > > > > Hi RagHu, > > > > Really appreciate your help. > > > > I was downloaded this software stack from git.linaro.org. This software > stack include ATF, kernel, edk2 and so on. > > The user guide i used from linaro is:https://git.linaro.org/landing- > teams/working/arm/arm-reference- > platforms.git/about/docs/rdn1edge/user-guide.rst#obtaining-the-rd-n1- > edge-and-rd-n1-edge-dual-fast-model > > > > 1) What platform you are running on? Can this issue be reproduced > > outside your testing environment, perhaps on FVP or QEMU? > > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this > FVP platform. > > > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > > commit-id, so that we can be sure we are looking at the same code. > > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git > tag:RD-INFRA-20191024-RC0 > > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 > and edk2-platform version information. if anything i missed, please let me > know. > > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git tag:RD- > INFRA-20191024-RC0 > > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2- > platforms.git tag:RD-INFRA-20191024-RC0 > > > > 3) What version of the kernel and sdei driver is being used? > > A: kernel-release: https://git.linaro.org/landing- > teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > > The sdei driver was included in kernel, do i need to provide sdei driver > version? If need please let me know. > > 4) I can't tell from looking at the log but do you know if writing 0x123 > > to sde_ras_poison causes a DMC620 interrupt or an SError or external > > abort through memory access ? > > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. > So I am also not sure which exception type it will trigger. > > > > BRs， > > Bin Wu > > > > ------------------原始邮件 ------------------ > > 发件人:TF-A > > > 发送时间:Tue Apr 14 01:25:47 2020 > > 收件人:Raghu Krishnamurthy via TF-A > > > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 > Crashed > > Hello, > > > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > > > I don't think it will. It is really odd that > > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM > handler. > > This is from looking at the upstream code quickly but it definitely > > depends on the platform you are running, what version of TF-A you are > > using, build options used. Is it possible that the unhandled exception > > is occurring after successful handling of the DMC620 error but there is > > a following issue that occurs right after, causing the crash? > > From the register dump it looks like there was an Instruction abort > > exception at address 0 while running in EL3. Something seems to have > > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > > an instruction abort at address 0. > > > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > > See above. The answer really depends on the factors mentioned above. > > > > The following would be helpful to know: > > 1) What platform you are running on? Can this issue be reproduced > > outside your testing environment, perhaps on FVP or QEMU? > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > > commit-id, so that we can be sure we are looking at the same code. > > 3) What version of the kernel and sdei driver is being used? > > 4) I can't tell from looking at the log but do you know if writing 0x123 > > to sde_ras_poison causes a DMC620 interrupt or an SError or external > > abort through memory access ? > > > > Thanks > > Raghu > > > > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: > >> Dear Friends, > >> > >> I am using TF-A to test RAS feature. > >> When I triggered DMC620 RAS error in Linux(echo 0x123 > > >> /sys/kernel/debug/sdei_ras_poison). > >> BL32 will recieve > >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and > finally > >> BL31 crashed. > >> > >> In my understanding, this 0xC4000061 should consumed by BL31, not > send > >> it to BL32 again. > >> > >> A piece of error log as below: > >> > >> ************************************* > >> > >> CperWrite - CperAddress@0xFF610064 > >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 > >> CperWrite - Got Error Section: Platform Memory. > >> MmEntryPoint Done > >> Received delegated event > >> X0 : 0xC4000061 > >> X1 : 0x0 > >> X2 : 0x0 > >> X3 : 0x0 > >> Received event - 0xC4000061 on cpu 0 > >> UnRecognized Event - 0xC4000061 > >> Failed delegated event 0xC4000061, Status 0x2 > >> Unhandled Exception in EL3. > >> x30 = 0x0000000000000000 > >> x0 = 0x00000000ff007e00 > >> x1 = 0xfffffffffffffffe > >> x2 = 0x00000000600003c0 > >> x3 = 0x0000000000000000 > >> x4 = 0x0000000000000000 > >> x5 = 0x0000000000000000 > >> x6 = 0x00000000ff015080 > >> x7 = 0x0000000000000000 > >> x8 = 0x00000000c4000061 > >> x9 = 0x0000000000000021 > >> x10 = 0x0000000000000040 > >> x11 = 0x00000000ff00f2b0 > >> x12 = 0x00000000ff0118c0 > >> x13 = 0x0000000000000002 > >> x14 = 0x00000000ff016b70 > >> x15 = 0x00000000ff003f20 > >> x16 = 0x0000000000000044 > >> x17 = 0x00000000ff010430 > >> x18 = 0x0000000000000e3c > >> x19 = 0x0000000000000000 > >> More error log please refer to attachment. > >> > >> My question is, > >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? > >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. > >> > >> Appreciate your help. > >> > >> BRs， > >> Bin Wu > >> > > -- > > 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 > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years

3
6
0 0

Re: [TF-A] Need input on Errata implementation

by Manish Badarkhe

Hi All, Just update/correct details. Thanks Manish Badarkhe On 27/04/2020, 22:13, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Raghu Please ignore my answer on question 2. With internal discussion came to below conclusion: 1. This workaround is very specific during context switching. 2 . If you check in context save routine (el1_sysregs_context_save or el2_sysregs_context_save), As per proposed solution, First step performed is to disable page table walk and we don’t have any AT instruction execution in context save routine. This ensures that there will be no possibility of speculative AT instruction execution without TCR update. 3. If you check in context restore routine (el1_sysregs_context_restore or el2_sysregs_context_restore), As per proposed solution, first step performed is to disable page table walk and we don’t have any AT instruction execution in context restore routine. This ensures that there will be no possibility of speculative AT instruction execution without TCR update. Hence proposed solution will work as it is ensuring no caching of translations in TLB while speculative AT instruction execution. Thanks Manish Badarkhe On 27/04/2020, 13:38, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Raghu Please see my answers inline On 25/04/2020, 06:38, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Manish, Before I agree or disagree with the suggested fix, the following would be interesting to know/discuss. Please feel free to correct me if i've misunderstood something. 1) Are "speculative" AT instructions subject to TCR_ELx control bits for all the listed CPU's? I imagine the answer is yes but would be good to get confirmation. I could not find any evidence in the instruction description or psuedocode in the ARMv8 ARM. It is possible to play many tricks on speculative execution of instructions such as skipping checks and doing them only when the CPU knows the instruction will be committed. If this is the case, changing TCR_ELx bits may not work. The errata document is vague about how to fix it. The speculative AT instruction may behave as you mentioned. We need more opinion on this. Proposed fix I mentioned by referring linux workaround for the same errata. Linux workaround is available in mainline kernel as below: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… 2) Assuming the answer to question 1 is yes, your proposal may not work as is. In the worst case, as soon as you enter EL3, the very first thing that may happen, before you ever operate/write to TCR_ELx, is a speculative AT instruction that caches a bad translation in the TLB's. The same thing can happen on the exit path. As soon as you restore the TCR_ELx register, the first thing that can happen is a speculative AT that caches a bad translation. However, the el3_exit path does have DSB before ERET, so we will not speculate to an AT instruction if there are no branches between the instruction that sets TCR_ELx and the ERET. Somewhere in between, it looks like we will need a TLBI NSH to be certain there are no bad translation cached. This obviously has a potential performance cost on the lower EL's. Every entry into EL3 flushes the TLB for lower EL's. Yes, this seems to be valid case during entry and exit path. I am not quite sure in that case where we need to avoid PTW. Also "TLBI NSH" works but it may cause performance issue. Need some more opinion/thoughts on this. Just thinking, can sequence mentioned for context save does not ensure that PTW is disabled? Something as below as last step in ELx(1/2) context save (elaborated more): > ·Save TCR register with PTW enable (EPD=0). (Just to enable PTW during > restore context). Do not operate TCR_EL1x register here just save its value to restore. > This ensures that during entry in EL3 there will be no chance of PTW >. while executing AT instruction. Thanks Raghu Thanks Manish Badarkhe On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > Hi All > > We are trying to implement errata which is applicable for below CPUs: > > <CPUs> : <Errata No.> > > Cortex-A53: 1530924 > > Cortex-A76: 1165522 > Cortex-A72: 1319367 > Cortex-A57: 1319537 > Cortex-A55: 1530923 > > *Errata Description:* > > A speculative Address Translation (AT) instruction translates using > registers that are associated with an out-of-context translation > regime and caches the resulting translation in the TLB. A subsequent > translation request that is generated when the out-of-context > translation regime is current uses the previous cached TLB entry > producing an incorrect virtual to physical mapping. > > *Probable solution is to implement below fix in context.S file:* > > *During ELx (1 or 2) context save:* > > ·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > oThis will avoid any page table walk for S-EL1 or S-EL2. This will > help in avoiding caching of translations in TLB > > for S-EL1/S-EL2 in EL3. > > ·Save all system registers (which is already available) except TCR > > ·Clear EPD bits of TCR and then save. (Just to enable PTW during > restore context). > > *During ELx (1 or 2) context restore:* > > * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > * Restore all system registers (which are saved during context save) > except TCR register. > * Restore TCR_ELx(1/2) register (which enable back PTW). > > With above we ensured that there will be no page table walk for S-EL1 > and S-EL2 in EL3. > > is this proper other way to fix this problem? Need some suggestion/use > cases where and all we need this workaround in TF-A code. > > Thanks > > Manish Badarkhe > > 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. > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years

3
6
0 0

Re: [TF-A] Need input on Errata implementation

by Manish Badarkhe

Hi Raghu Please ignore my answer on question 2. With internal discussion came to below conclusion: 1. This workaround is very specific during context switching. 2 . If you check in context save routine (el1_sysregs_context_save or el2_sysregs_context_save), First step performed is to disable page table walk and Also, we don’t have any AT instruction execution in that context save routing. This ensures that there will be no possibility of speculative AT instruction execution without TCR update. 3. If you check in context save routine (el1_sysregs_context_restore or el2_sysregs_context_restore), first step performed is to disable page table walk and Also, we don’t have any AT instruction execution in that path. This ensures that there will be no possibility of speculative AT instruction execution without TCR update. Hence proposed solution will work as it is ensuring no caching of translations in TLB while speculative AT instruction execution. Thanks Manish Badarkhe On 27/04/2020, 13:38, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Raghu Please see my answers inline On 25/04/2020, 06:38, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Manish, Before I agree or disagree with the suggested fix, the following would be interesting to know/discuss. Please feel free to correct me if i've misunderstood something. 1) Are "speculative" AT instructions subject to TCR_ELx control bits for all the listed CPU's? I imagine the answer is yes but would be good to get confirmation. I could not find any evidence in the instruction description or psuedocode in the ARMv8 ARM. It is possible to play many tricks on speculative execution of instructions such as skipping checks and doing them only when the CPU knows the instruction will be committed. If this is the case, changing TCR_ELx bits may not work. The errata document is vague about how to fix it. The speculative AT instruction may behave as you mentioned. We need more opinion on this. Proposed fix I mentioned by referring linux workaround for the same errata. Linux workaround is available in mainline kernel as below: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… 2) Assuming the answer to question 1 is yes, your proposal may not work as is. In the worst case, as soon as you enter EL3, the very first thing that may happen, before you ever operate/write to TCR_ELx, is a speculative AT instruction that caches a bad translation in the TLB's. The same thing can happen on the exit path. As soon as you restore the TCR_ELx register, the first thing that can happen is a speculative AT that caches a bad translation. However, the el3_exit path does have DSB before ERET, so we will not speculate to an AT instruction if there are no branches between the instruction that sets TCR_ELx and the ERET. Somewhere in between, it looks like we will need a TLBI NSH to be certain there are no bad translation cached. This obviously has a potential performance cost on the lower EL's. Every entry into EL3 flushes the TLB for lower EL's. Yes, this seems to be valid case during entry and exit path. I am not quite sure in that case where we need to avoid PTW. Also "TLBI NSH" works but it may cause performance issue. Need some more opinion/thoughts on this. Just thinking, can sequence mentioned for context save does not ensure that PTW is disabled? Something as below as last step in ELx(1/2) context save (elaborated more): > ·Save TCR register with PTW enable (EPD=0). (Just to enable PTW during > restore context). Do not operate TCR_EL1x register here just save its value to restore. > This ensures that during entry in EL3 there will be no chance of PTW >. while executing AT instruction. Thanks Raghu Thanks Manish Badarkhe On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > Hi All > > We are trying to implement errata which is applicable for below CPUs: > > <CPUs> : <Errata No.> > > Cortex-A53: 1530924 > > Cortex-A76: 1165522 > Cortex-A72: 1319367 > Cortex-A57: 1319537 > Cortex-A55: 1530923 > > *Errata Description:* > > A speculative Address Translation (AT) instruction translates using > registers that are associated with an out-of-context translation > regime and caches the resulting translation in the TLB. A subsequent > translation request that is generated when the out-of-context > translation regime is current uses the previous cached TLB entry > producing an incorrect virtual to physical mapping. > > *Probable solution is to implement below fix in context.S file:* > > *During ELx (1 or 2) context save:* > > ·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > oThis will avoid any page table walk for S-EL1 or S-EL2. This will > help in avoiding caching of translations in TLB > > for S-EL1/S-EL2 in EL3. > > ·Save all system registers (which is already available) except TCR > > ·Clear EPD bits of TCR and then save. (Just to enable PTW during > restore context). > > *During ELx (1 or 2) context restore:* > > * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > * Restore all system registers (which are saved during context save) > except TCR register. > * Restore TCR_ELx(1/2) register (which enable back PTW). > > With above we ensured that there will be no page table walk for S-EL1 > and S-EL2 in EL3. > > is this proper other way to fix this problem? Need some suggestion/use > cases where and all we need this workaround in TF-A code. > > Thanks > > Manish Badarkhe > > 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. > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years

1
0
0 0

Re: [TF-A] Need input on Errata implementation

by Manish Badarkhe

Hi Raghu Please see my answers inline On 25/04/2020, 06:38, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Manish, Before I agree or disagree with the suggested fix, the following would be interesting to know/discuss. Please feel free to correct me if i've misunderstood something. 1) Are "speculative" AT instructions subject to TCR_ELx control bits for all the listed CPU's? I imagine the answer is yes but would be good to get confirmation. I could not find any evidence in the instruction description or psuedocode in the ARMv8 ARM. It is possible to play many tricks on speculative execution of instructions such as skipping checks and doing them only when the CPU knows the instruction will be committed. If this is the case, changing TCR_ELx bits may not work. The errata document is vague about how to fix it. The speculative AT instruction may behave as you mentioned. We need more opinion on this. Proposed fix I mentioned by referring linux workaround for the same errata. Linux workaround is available in mainline kernel as below: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… 2) Assuming the answer to question 1 is yes, your proposal may not work as is. In the worst case, as soon as you enter EL3, the very first thing that may happen, before you ever operate/write to TCR_ELx, is a speculative AT instruction that caches a bad translation in the TLB's. The same thing can happen on the exit path. As soon as you restore the TCR_ELx register, the first thing that can happen is a speculative AT that caches a bad translation. However, the el3_exit path does have DSB before ERET, so we will not speculate to an AT instruction if there are no branches between the instruction that sets TCR_ELx and the ERET. Somewhere in between, it looks like we will need a TLBI NSH to be certain there are no bad translation cached. This obviously has a potential performance cost on the lower EL's. Every entry into EL3 flushes the TLB for lower EL's. Yes, this seems to be valid case during entry and exit path. I am not quite sure in that case where we need to avoid PTW. Also "TLBI NSH" works but it may cause performance issue. Need some more opinion/thoughts on this. Just thinking, can sequence mentioned for context save does not ensure that PTW is disabled? Something as below as last step in ELx(1/2) context save (elaborated more): > ·Save TCR register with PTW enable (EPD=0). (Just to enable PTW during > restore context). Do not operate TCR_EL1x register here just save its value to restore. > This ensures that during entry in EL3 there will be no chance of PTW >. while executing AT instruction. Thanks Raghu Thanks Manish Badarkhe On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > Hi All > > We are trying to implement errata which is applicable for below CPUs: > > <CPUs> : <Errata No.> > > Cortex-A53: 1530924 > > Cortex-A76: 1165522 > Cortex-A72: 1319367 > Cortex-A57: 1319537 > Cortex-A55: 1530923 > > *Errata Description:* > > A speculative Address Translation (AT) instruction translates using > registers that are associated with an out-of-context translation > regime and caches the resulting translation in the TLB. A subsequent > translation request that is generated when the out-of-context > translation regime is current uses the previous cached TLB entry > producing an incorrect virtual to physical mapping. > > *Probable solution is to implement below fix in context.S file:* > > *During ELx (1 or 2) context save:* > > ·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > oThis will avoid any page table walk for S-EL1 or S-EL2. This will > help in avoiding caching of translations in TLB > > for S-EL1/S-EL2 in EL3. > > ·Save all system registers (which is already available) except TCR > > ·Clear EPD bits of TCR and then save. (Just to enable PTW during > restore context). > > *During ELx (1 or 2) context restore:* > > * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > * Restore all system registers (which are saved during context save) > except TCR register. > * Restore TCR_ELx(1/2) register (which enable back PTW). > > With above we ensured that there will be no page table walk for S-EL1 > and S-EL2 in EL3. > > is this proper other way to fix this problem? Need some suggestion/use > cases where and all we need this workaround in TF-A code. > > Thanks > > Manish Badarkhe > > 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. > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years

1
0
0 0

Re: [TF-A] Need input on Errata implementation

by Raghu K

Hi Manish, Before I agree or disagree with the suggested fix, the following would be interesting to know/discuss. Please feel free to correct me if i've misunderstood something. 1) Are "speculative" AT instructions subject to TCR_ELx control bits for all the listed CPU's? I imagine the answer is yes but would be good to get confirmation. I could not find any evidence in the instruction description or psuedocode in the ARMv8 ARM. It is possible to play many tricks on speculative execution of instructions such as skipping checks and doing them only when the CPU knows the instruction will be committed. If this is the case, changing TCR_ELx bits may not work. The errata document is vague about how to fix it. 2) Assuming the answer to question 1 is yes, your proposal may not work as is. In the worst case, as soon as you enter EL3, the very first thing that may happen, before you ever operate/write to TCR_ELx, is a speculative AT instruction that caches a bad translation in the TLB's. The same thing can happen on the exit path. As soon as you restore the TCR_ELx register, the first thing that can happen is a speculative AT that caches a bad translation. However, the el3_exit path does have DSB before ERET, so we will not speculate to an AT instruction if there are no branches between the instruction that sets TCR_ELx and the ERET. Somewhere in between, it looks like we will need a TLBI NSH to be certain there are no bad translation cached. This obviously has a potential performance cost on the lower EL's. Every entry into EL3 flushes the TLB for lower EL's. Thanks Raghu On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote: > > Hi All > > We are trying to implement errata which is applicable for below CPUs: > > <CPUs> : <Errata No.> > > Cortex-A53: 1530924 > > Cortex-A76: 1165522 > Cortex-A72: 1319367 > Cortex-A57: 1319537 > Cortex-A55: 1530923 > > *Errata Description:* > > A speculative Address Translation (AT) instruction translates using > registers that are associated with an out-of-context translation > regime and caches the resulting translation in the TLB. A subsequent > translation request that is generated when the out-of-context > translation regime is current uses the previous cached TLB entry > producing an incorrect virtual to physical mapping. > > *Probable solution is to implement below fix in context.S file:* > > *During ELx (1 or 2) context save:* > > ·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > > oThis will avoid any page table walk for S-EL1 or S-EL2. This will > help in avoiding caching of translations in TLB > > for S-EL1/S-EL2 in EL3. > > ·Save all system registers (which is already available) except TCR > > ·Clear EPD bits of TCR and then save. (Just to enable PTW during > restore context). > > *During ELx (1 or 2) context restore:* > > * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits > * Restore all system registers (which are saved during context save) > except TCR register. > * Restore TCR_ELx(1/2) register (which enable back PTW). > > With above we ensured that there will be no page table walk for S-EL1 > and S-EL2 in EL3. > > is this proper other way to fix this problem? Need some suggestion/use > cases where and all we need this workaround in TF-A code. > > Thanks > > Manish Badarkhe > > 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. >

6 years, 1 month

1
0
0 0

Need input on Errata implementation

by Manish Badarkhe

Hi All We are trying to implement errata which is applicable for below CPUs: <CPUs> : <Errata No.> Cortex-A53: 1530924 Cortex-A76: 1165522 Cortex-A72: 1319367 Cortex-A57: 1319537 Cortex-A55: 1530923 Errata Description: A speculative Address Translation (AT) instruction translates using registers that are associated with an out-of-context translation regime and caches the resulting translation in the TLB. A subsequent translation request that is generated when the out-of-context translation regime is current uses the previous cached TLB entry producing an incorrect virtual to physical mapping. Probable solution is to implement below fix in context.S file: During ELx (1 or 2) context save: · Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits o This will avoid any page table walk for S-EL1 or S-EL2. This will help in avoiding caching of translations in TLB for S-EL1/S-EL2 in EL3. · Save all system registers (which is already available) except TCR · Clear EPD bits of TCR and then save. (Just to enable PTW during restore context). During ELx (1 or 2) context restore: * Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits * Restore all system registers (which are saved during context save) except TCR register. * Restore TCR_ELx(1/2) register (which enable back PTW). With above we ensured that there will be no page table walk for S-EL1 and S-EL2 in EL3. is this proper other way to fix this problem? Need some suggestion/use cases where and all we need this workaround in TF-A code. Thanks Manish Badarkhe 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.

6 years, 1 month

1
0
0 0

Re: [TF-A] Event Log for Measured Boot

by Sandrine Bailleux

Hi, On 4/21/20 7:23 AM, Soby Mathew via TF-A wrote: > My view is that smaller patches are easier to review and we should try to break up the patches to logical chucks where possible. I haven't taken a look at the patches myself but I am sure there will be ways to break it up for ease of review. I would like to strongly echo this. I find big patches so hard to review. There is only so much things the human brain can comprehend in one go. Smaller patches are just easier to reason about, they focus on one thing and it is easier to get your head around them because the entire patch and the interaction it may have with other components "fits" in one's head. Thus, it is much easier to reach a good level of confidence at review time. Also, I believe there is a natural tendency of getting discouraged at the sight of big patches, smaller patches have a much better chance of getting reviewed quickly. They can also be dealt with incrementally. Say in a 10 patch stack, it may happen that the 5 first are good to go, while the sixth is more controversial and requires more discussion. In this case, being able to merge the 5 patches is a first step in the right direction. Ideally, one should think about how to split the patches in a logical, manageable way early during development. It is true that if it is an afterthought, breaking up a huge patch down into smaller ones is a lot of work. This is why it needs doing upfront IMO. Cheers, Sandrine

6 years, 1 month

1
0
0 0

Re: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Thomas Abraham

[resending as the previous email was sent to the wrong address] Hi, Looking into the mail chain below, this is probably being tested on RD-N1-Edge platform. There was regression noticed in the dmc620 ras error handling in the code pushed to Linaro for RD-N1-Edge platform. This will be fixed later today and patches will be merged into Linaro repos. It should then be accessible using the usual repo init/sync commands. Thanks, Thomas. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier > Deprez via TF-A > Sent: Tuesday, April 21, 2020 4:45 PM > To: TF-A <tf-a-bounces(a)lists.trustedfirmware.org>; Raghu K via TF-A <tf- > a(a)lists.trustedfirmware.org>; 吴斌(郅隆) <zhilong.wb(a)alibaba-inc.com> > Subject: Re: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - > 0xC4000061 and BL31 Crashed > > Hi Raghu, > > Yes you're right, we probably need few return code checks here and here. I > may submit a patch and verify it doesn't break anything else. > > Hi Bin Wu, > > I had noticed the following sequence originating from linux sdei driver init > down to TF-A: > > INFO: SDEI: Private events initialized on 81000100 > INFO: SDEI: Private events initialized on 81000200 > INFO: SDEI: Private events initialized on 81000300 > INFO: SDEI: Private events initialized on 81010000 > INFO: SDEI: Private events initialized on 81010100 > INFO: SDEI: Private events initialized on 81010200 > INFO: SDEI: Private events initialized on 81010300 > INFO: SDEI: > VER > INFO: SDEI: < VER:1000000000000 > INFO: SDEI: > P_RESET():81000000 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000200 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000300 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010000 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010100 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010200 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81010300 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > P_RESET():81000100 > INFO: SDEI: < P_RESET:0 > INFO: SDEI: > S_RESET():81000100 > INFO: SDEI: < S_RESET:0 > INFO: SDEI: > UNMASK:81000000 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000100 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000200 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81000300 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010000 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010100 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010200 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > UNMASK:81010300 > INFO: SDEI: < UNMASK:0 > INFO: SDEI: > INFO(n:804, 0) > INFO: SDEI: < INFO:0 > INFO: SDEI: > INFO(n:805, 0) > INFO: SDEI: < INFO:0 > > There is an Sdei Info request about events 804 and 805. > Although I don't see any register or enable event service call, so I wonder if > this demo code is missing something or expects that the platform > implements such event definition natively. > > This does not look like flows described in https://trustedfirmware- > a.readthedocs.io/en/latest/components/sdei.html > for regular SDEI usage or explicit dispatch of events. > > Maybe we should involve Linaro ppl on the expected init sequence and > dependency to TF-A (platform files). > > Regards, > Olivier. > > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅 > 隆) via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 21 April 2020 08:45 > To: TF-A; Raghu K via TF-A > Subject: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - > 0xC4000061 and BL31 Crashed > > Hi Olivier and All, > > Thank you so much for your help. It makes me understand the internals. > The next step, I need to check this event_num(804) register flow in kernel > side, am I right? > > > BRs， > Bin Wu > ------------------原始邮件 ------------------ > 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > 发送时间:Tue Apr 21 09:51:49 2020 > 收件人:Raghu K via TF-A <tf-a(a)lists.trustedfirmware.org> > 主题:Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and > BL31 Crashed > Nice debug! Apart from the issue you pointed out, there is also the > issue with not checking the return code. The ras handler should really > be checking or panic'ing if there is an unexpected error code from > spm_sp_call and sdei_dispatch_event. > > -Raghu > > On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > > Hi Bin Wu, > > > > Here's an early observation. On receiving the RAS fiq interrupt the > following occurs: > > > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call > (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > > > se = get_event_entry(map); > > if (!can_sdei_state_trans(se, DO_DISPATCH)) > > return -1; > > > > p *map > > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = > 0}} > > p *se > > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > > > sdei_dispatch_event exits in error at this stage, this does not seem a > correct behavior. > > The SDEI handler is not called in NS world and context remains unchanged. > > The interrupt handler blindly returns to S-EL1 SP context at same location > where it last exited. > > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry > fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > > SP then exits but the EL3 context has not been setup for SP entry leading > to crash. > > > > IMO there is an issue around mapping SDEI event number to RAS interrupt > number leading to sdei_dispatch_event exiting early. > > > > Regards, > > Olivier. > > > > > > ________________________________________ > > From: TF-A on behalf of Matteo Carlini via TF-A > > Sent: 14 April 2020 10:41 > > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak > Pandey > > Cc: nd > > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 > and BL31 Crashed > > > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team > platforms releases. They might be able to help. > > > > Thanks > > Matteo > > > > From: TF-A On Behalf Of ??(??) via TF-A > > Sent: 14 April 2020 06:47 > > To: TF-A ; Raghu Krishnamurthy via TF-A > > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 > and BL31 Crashed > > > > Hi RagHu, > > > > Really appreciate your help. > > > > I was downloaded this software stack from git.linaro.org. This software > stack include ATF, kernel, edk2 and so on. > > The user guide i used from linaro is:https://git.linaro.org/landing- > teams/working/arm/arm-reference- > platforms.git/about/docs/rdn1edge/user-guide.rst#obtaining-the-rd-n1- > edge-and-rd-n1-edge-dual-fast-model > > > > 1) What platform you are running on? Can this issue be reproduced > > outside your testing environment, perhaps on FVP or QEMU? > > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this > FVP platform. > > > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > > commit-id, so that we can be sure we are looking at the same code. > > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git > tag:RD-INFRA-20191024-RC0 > > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 > and edk2-platform version information. if anything i missed, please let me > know. > > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git tag:RD- > INFRA-20191024-RC0 > > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2- > platforms.git tag:RD-INFRA-20191024-RC0 > > > > 3) What version of the kernel and sdei driver is being used? > > A: kernel-release: https://git.linaro.org/landing- > teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > > The sdei driver was included in kernel, do i need to provide sdei driver > version? If need please let me know. > > 4) I can't tell from looking at the log but do you know if writing 0x123 > > to sde_ras_poison causes a DMC620 interrupt or an SError or external > > abort through memory access ? > > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. > So I am also not sure which exception type it will trigger. > > > > BRs， > > Bin Wu > > > > ------------------原始邮件 ------------------ > > 发件人:TF-A > > > 发送时间:Tue Apr 14 01:25:47 2020 > > 收件人:Raghu Krishnamurthy via TF-A > > > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 > Crashed > > Hello, > > > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > > > I don't think it will. It is really odd that > > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM > handler. > > This is from looking at the upstream code quickly but it definitely > > depends on the platform you are running, what version of TF-A you are > > using, build options used. Is it possible that the unhandled exception > > is occurring after successful handling of the DMC620 error but there is > > a following issue that occurs right after, causing the crash? > > From the register dump it looks like there was an Instruction abort > > exception at address 0 while running in EL3. Something seems to have > > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > > an instruction abort at address 0. > > > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > > See above. The answer really depends on the factors mentioned above. > > > > The following would be helpful to know: > > 1) What platform you are running on? Can this issue be reproduced > > outside your testing environment, perhaps on FVP or QEMU? > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > > commit-id, so that we can be sure we are looking at the same code. > > 3) What version of the kernel and sdei driver is being used? > > 4) I can't tell from looking at the log but do you know if writing 0x123 > > to sde_ras_poison causes a DMC620 interrupt or an SError or external > > abort through memory access ? > > > > Thanks > > Raghu > > > > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: > >> Dear Friends, > >> > >> I am using TF-A to test RAS feature. > >> When I triggered DMC620 RAS error in Linux(echo 0x123 > > >> /sys/kernel/debug/sdei_ras_poison). > >> BL32 will recieve > >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and > finally > >> BL31 crashed. > >> > >> In my understanding, this 0xC4000061 should consumed by BL31, not > send > >> it to BL32 again. > >> > >> A piece of error log as below: > >> > >> ************************************* > >> > >> CperWrite - CperAddress@0xFF610064 > >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 > >> CperWrite - Got Error Section: Platform Memory. > >> MmEntryPoint Done > >> Received delegated event > >> X0 : 0xC4000061 > >> X1 : 0x0 > >> X2 : 0x0 > >> X3 : 0x0 > >> Received event - 0xC4000061 on cpu 0 > >> UnRecognized Event - 0xC4000061 > >> Failed delegated event 0xC4000061, Status 0x2 > >> Unhandled Exception in EL3. > >> x30 = 0x0000000000000000 > >> x0 = 0x00000000ff007e00 > >> x1 = 0xfffffffffffffffe > >> x2 = 0x00000000600003c0 > >> x3 = 0x0000000000000000 > >> x4 = 0x0000000000000000 > >> x5 = 0x0000000000000000 > >> x6 = 0x00000000ff015080 > >> x7 = 0x0000000000000000 > >> x8 = 0x00000000c4000061 > >> x9 = 0x0000000000000021 > >> x10 = 0x0000000000000040 > >> x11 = 0x00000000ff00f2b0 > >> x12 = 0x00000000ff0118c0 > >> x13 = 0x0000000000000002 > >> x14 = 0x00000000ff016b70 > >> x15 = 0x00000000ff003f20 > >> x16 = 0x0000000000000044 > >> x17 = 0x00000000ff010430 > >> x18 = 0x0000000000000e3c > >> x19 = 0x0000000000000000 > >> More error log please refer to attachment. > >> > >> My question is, > >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? > >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. > >> > >> Appreciate your help. > >> > >> BRs， > >> Bin Wu > >> > > -- > > 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 > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years, 1 month

1
0
0 0

Re: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Olivier Deprez

Hi Raghu, Yes you're right, we probably need few return code checks here and here. I may submit a patch and verify it doesn't break anything else. Hi Bin Wu, I had noticed the following sequence originating from linux sdei driver init down to TF-A: INFO: SDEI: Private events initialized on 81000100 INFO: SDEI: Private events initialized on 81000200 INFO: SDEI: Private events initialized on 81000300 INFO: SDEI: Private events initialized on 81010000 INFO: SDEI: Private events initialized on 81010100 INFO: SDEI: Private events initialized on 81010200 INFO: SDEI: Private events initialized on 81010300 INFO: SDEI: > VER INFO: SDEI: < VER:1000000000000 INFO: SDEI: > P_RESET():81000000 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81000200 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81000300 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81010000 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81010100 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81010200 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81010300 INFO: SDEI: < P_RESET:0 INFO: SDEI: > P_RESET():81000100 INFO: SDEI: < P_RESET:0 INFO: SDEI: > S_RESET():81000100 INFO: SDEI: < S_RESET:0 INFO: SDEI: > UNMASK:81000000 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81000100 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81000200 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81000300 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81010000 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81010100 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81010200 INFO: SDEI: < UNMASK:0 INFO: SDEI: > UNMASK:81010300 INFO: SDEI: < UNMASK:0 INFO: SDEI: > INFO(n:804, 0) INFO: SDEI: < INFO:0 INFO: SDEI: > INFO(n:805, 0) INFO: SDEI: < INFO:0 There is an Sdei Info request about events 804 and 805. Although I don't see any register or enable event service call, so I wonder if this demo code is missing something or expects that the platform implements such event definition natively. This does not look like flows described in https://trustedfirmware-a.readthedocs.io/en/latest/components/sdei.html for regular SDEI usage or explicit dispatch of events. Maybe we should involve Linaro ppl on the expected init sequence and dependency to TF-A (platform files). Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅隆) via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 April 2020 08:45 To: TF-A; Raghu K via TF-A Subject: [TF-A] 回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hi Olivier and All, Thank you so much for your help. It makes me understand the internals. The next step, I need to check this event_num(804) register flow in kernel side, am I right? BRs， Bin Wu ------------------原始邮件 ------------------ 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org> 发送时间:Tue Apr 21 09:51:49 2020 收件人:Raghu K via TF-A <tf-a(a)lists.trustedfirmware.org> 主题:Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Nice debug! Apart from the issue you pointed out, there is also the issue with not checking the return code. The ras handler should really be checking or panic'ing if there is an unexpected error code from spm_sp_call and sdei_dispatch_event. -Raghu On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > Hi Bin Wu, > > Here's an early observation. On receiving the RAS fiq interrupt the following occurs: > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > se = get_event_entry(map); > if (!can_sdei_state_trans(se, DO_DISPATCH)) > return -1; > > p *map > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} > p *se > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. > The SDEI handler is not called in NS world and context remains unchanged. > The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > SP then exits but the EL3 context has not been setup for SP entry leading to crash. > > IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. > > Regards, > Olivier. > > > ________________________________________ > From: TF-A on behalf of Matteo Carlini via TF-A > Sent: 14 April 2020 10:41 > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey > Cc: nd > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. > > Thanks > Matteo > > From: TF-A On Behalf Of ??(??) via TF-A > Sent: 14 April 2020 06:47 > To: TF-A ; Raghu Krishnamurthy via TF-A > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Hi RagHu, > > Really appreciate your help. > > I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. > The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… > > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git tag:RD-INFRA-20191024-RC0 > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git tag:RD-INFRA-20191024-RC0 > > 3) What version of the kernel and sdei driver is being used? > A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. > > BRs， > Bin Wu > > ------------------原始邮件 ------------------ > 发件人:TF-A > > 发送时间:Tue Apr 14 01:25:47 2020 > 收件人:Raghu Krishnamurthy via TF-A > > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > Hello, > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > I don't think it will. It is really odd that > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. > This is from looking at the upstream code quickly but it definitely > depends on the platform you are running, what version of TF-A you are > using, build options used. Is it possible that the unhandled exception > is occurring after successful handling of the DMC620 error but there is > a following issue that occurs right after, causing the crash? > From the register dump it looks like there was an Instruction abort > exception at address 0 while running in EL3. Something seems to have > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > an instruction abort at address 0. > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > See above. The answer really depends on the factors mentioned above. > > The following would be helpful to know: > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > 3) What version of the kernel and sdei driver is being used? > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > > Thanks > Raghu > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: >> Dear Friends, >> >> I am using TF-A to test RAS feature. >> When I triggered DMC620 RAS error in Linux(echo 0x123 > >> /sys/kernel/debug/sdei_ras_poison). >> BL32 will recieve >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally >> BL31 crashed. >> >> In my understanding, this 0xC4000061 should consumed by BL31, not send >> it to BL32 again. >> >> A piece of error log as below: >> >> ************************************* >> >> CperWrite - CperAddress@0xFF610064 >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 >> CperWrite - Got Error Section: Platform Memory. >> MmEntryPoint Done >> Received delegated event >> X0 : 0xC4000061 >> X1 : 0x0 >> X2 : 0x0 >> X3 : 0x0 >> Received event - 0xC4000061 on cpu 0 >> UnRecognized Event - 0xC4000061 >> Failed delegated event 0xC4000061, Status 0x2 >> Unhandled Exception in EL3. >> x30 = 0x0000000000000000 >> x0 = 0x00000000ff007e00 >> x1 = 0xfffffffffffffffe >> x2 = 0x00000000600003c0 >> x3 = 0x0000000000000000 >> x4 = 0x0000000000000000 >> x5 = 0x0000000000000000 >> x6 = 0x00000000ff015080 >> x7 = 0x0000000000000000 >> x8 = 0x00000000c4000061 >> x9 = 0x0000000000000021 >> x10 = 0x0000000000000040 >> x11 = 0x00000000ff00f2b0 >> x12 = 0x00000000ff0118c0 >> x13 = 0x0000000000000002 >> x14 = 0x00000000ff016b70 >> x15 = 0x00000000ff003f20 >> x16 = 0x0000000000000044 >> x17 = 0x00000000ff010430 >> x18 = 0x0000000000000e3c >> x19 = 0x0000000000000000 >> More error log please refer to attachment. >> >> My question is, >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. >> >> Appreciate your help. >> >> BRs， >> Bin Wu >> > -- > 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 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.

6 years, 1 month

1
0
0 0

TF-A Tech Forum Agenda @ Thr 23rd Apr 2020 17:00-1800 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 23rd Apr 2020 17:00 - 18: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: * Overview of the TF-A v2.3 Release by Bipin Ravi and Mark Dykes * Project Maintenance Proposal for tf.org Projects discussion * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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.

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] isolation between runtime BL33 services and OS

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François > Ozog via TF-A > Sent: 20 April 2020 16:25 > To: Achin Gupta <Achin.Gupta(a)arm.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] [RFC] isolation between runtime BL33 services and OS > > On Mon, 20 Apr 2020 at 15:50, Achin Gupta <achin.gupta(a)arm.com> wrote: > > > > On Mon, Apr 20, 2020 at 03:37:23PM +0200, François Ozog wrote: > > > On Mon, 20 Apr 2020 at 15:27, Achin Gupta <[1]achin.gupta(a)arm.com> > > > wrote: > > > > > > Hi Francois, > > > On Mon, Apr 20, 2020 at 11:45:02AM +0000, Fran ois Ozog via TF-A > > > wrote: > > > > Hi, > > > > > > > > I am trying to identify a mechanism to enforce a form of two-way > > > > isolation between BL33 runtime services in OS, for instance: > > > > - a pair of 2MB areas that could be RO by one entity and RW by the > > > other > > > > - an execute only BL33 2MB area? > > > Stupid Q! Are you referring to isolation between EFI runtime > > > services and the > > > OS? > > > It is not clear what you mean by BL33 runtime services? > > > > > > Not a stupid Q. I concentrate effectively on EFI runtime but more > > > generally this is the non-trusted firmware component that delivers > > > runtime services to OS. > > > (My flow is somewhat convoluted: TFA loads minimal Linux as BL33, Linux > > > kexecs a UEFI reduced U-Boot (without drivers) which bootefi the > > > distro). > > > > Thanks! I see and IIUC, this is about two separately provisioned SW > > components that share an EL (EL1 in this case) at the same time in the > > same image. We want component A to have permission X on a memory > > region and component B to have permission Y on the same memory region. > > If so, then this would require a cooperation between the two components? > > > Yes. Well cooperation is what happens today: Component A (UEFI compliant > FW) tells component B not to use memory it occupies. > I wish an EL(+n) component to make that a guarantee. Yet I don't want to > have "virtualization". > > > I might be still missing the obvious but I am wondering how a SW > > entity at a higher EL (Hypervisor in EL2 or TF-A in EL3) could create > > and enforce the separation between the two components. It would not > > have visibility of what is happening inside the EL at the very least. > > I hoped that by installing a page mapping "power play", we could enforce > some policy. > Performance here is not important because those data and context changes > seldomly happen. > I assume components A and B have a different mapping for the same "physical > page": > - EL1_A(VA)-> IA1; EL1_B(VA)->IA2 > - EL2(IA1) -> PA (RW), EL2(IA2)->PA(RO) or "not present" > A collaboration between UEFI FW and EL2/3 would allow that to happen. > A call to UEFI runtime service from SystemTable would result in a swap of > TTBR1 (from EL1_B to EL1_A) so that execution can continue in UEFI. > (I have no solution, just trying to check if we can find one). > HI Francois, What you suggest is possible AFAICS, as you suggest, if you create 2 IPAs with corresponding VAs. Communication between the 2 would involve some shared memory and invoking EL2 to trigger the switch between the VAs. This is suited more for an EL2 design I think rather than EL3. Best Regards Soby Mathew > > > > cheers, > > Achin > > > > > > > > cheers, > > > Achin > > > > > > > > This is similar to hypervisor except it only deals with memory, no > > > > vCPU, no GIC virtualization... > > > > > > > > Could EL3 or EL2 install protective mappings ? BL33 could ask > > > either > > > > EL2 hypervisor or SecureMonitor to actually install them. > > > > > > > > Cordially, > > > > > > > > FF > > > > -- > > > > TF-A mailing list > > > > [2]TF-A(a)lists.trustedfirmware.org > > > > [3]https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > 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. > > > > > > -- > > > [uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&export=download] > > > Fran ois-Fr d ric Ozog | Director Linaro Edge & Fog Computing Group > > > T: +33.67221.6485 > > > [4]francois.ozog(a)linaro.org | Skype: ffozog > > > > > > References > > > > > > 1. mailto:achin.gupta@arm.com > > > 2. mailto:TF-A@lists.trustedfirmware.org > > > 3. https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > 4. mailto:francois.ozog@linaro.org > > 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. > > > > -- > François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group > T: +33.67221.6485 > francois.ozog(a)linaro.org | Skype: ffozog > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years, 1 month

1
0
0 0

回复：Re: 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by 吴斌(郅隆)

Hi Olivier and All, Thank you so much for your help. It makes me understand the internals. The next step, I need to check this event_num(804) register flow in kernel side, am I right? BRs， Bin Wu ------------------原始邮件 ------------------ 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org> 发送时间:Tue Apr 21 09:51:49 2020 收件人:Raghu K via TF-A <tf-a(a)lists.trustedfirmware.org> 主题:Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Nice debug! Apart from the issue you pointed out, there is also the issue with not checking the return code. The ras handler should really be checking or panic'ing if there is an unexpected error code from spm_sp_call and sdei_dispatch_event. -Raghu On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > Hi Bin Wu, > > Here's an early observation. On receiving the RAS fiq interrupt the following occurs: > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > se = get_event_entry(map); > if (!can_sdei_state_trans(se, DO_DISPATCH)) > return -1; > > p *map > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} > p *se > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. > The SDEI handler is not called in NS world and context remains unchanged. > The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > SP then exits but the EL3 context has not been setup for SP entry leading to crash. > > IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. > > Regards, > Olivier. > > > ________________________________________ > From: TF-A on behalf of Matteo Carlini via TF-A > Sent: 14 April 2020 10:41 > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey > Cc: nd > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. > > Thanks > Matteo > > From: TF-A On Behalf Of ??(??) via TF-A > Sent: 14 April 2020 06:47 > To: TF-A ; Raghu Krishnamurthy via TF-A > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Hi RagHu, > > Really appreciate your help. > > I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. > The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… > > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git tag:RD-INFRA-20191024-RC0 > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git tag:RD-INFRA-20191024-RC0 > > 3) What version of the kernel and sdei driver is being used? > A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. > > BRs， > Bin Wu > > ------------------原始邮件 ------------------ > 发件人:TF-A > > 发送时间:Tue Apr 14 01:25:47 2020 > 收件人:Raghu Krishnamurthy via TF-A > > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > Hello, > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > I don't think it will. It is really odd that > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. > This is from looking at the upstream code quickly but it definitely > depends on the platform you are running, what version of TF-A you are > using, build options used. Is it possible that the unhandled exception > is occurring after successful handling of the DMC620 error but there is > a following issue that occurs right after, causing the crash? > From the register dump it looks like there was an Instruction abort > exception at address 0 while running in EL3. Something seems to have > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > an instruction abort at address 0. > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > See above. The answer really depends on the factors mentioned above. > > The following would be helpful to know: > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > 3) What version of the kernel and sdei driver is being used? > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > > Thanks > Raghu > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: >> Dear Friends, >> >> I am using TF-A to test RAS feature. >> When I triggered DMC620 RAS error in Linux(echo 0x123 > >> /sys/kernel/debug/sdei_ras_poison). >> BL32 will recieve >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally >> BL31 crashed. >> >> In my understanding, this 0xC4000061 should consumed by BL31, not send >> it to BL32 again. >> >> A piece of error log as below: >> >> ************************************* >> >> CperWrite - CperAddress@0xFF610064 >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 >> CperWrite - Got Error Section: Platform Memory. >> MmEntryPoint Done >> Received delegated event >> X0 : 0xC4000061 >> X1 : 0x0 >> X2 : 0x0 >> X3 : 0x0 >> Received event - 0xC4000061 on cpu 0 >> UnRecognized Event - 0xC4000061 >> Failed delegated event 0xC4000061, Status 0x2 >> Unhandled Exception in EL3. >> x30 = 0x0000000000000000 >> x0 = 0x00000000ff007e00 >> x1 = 0xfffffffffffffffe >> x2 = 0x00000000600003c0 >> x3 = 0x0000000000000000 >> x4 = 0x0000000000000000 >> x5 = 0x0000000000000000 >> x6 = 0x00000000ff015080 >> x7 = 0x0000000000000000 >> x8 = 0x00000000c4000061 >> x9 = 0x0000000000000021 >> x10 = 0x0000000000000040 >> x11 = 0x00000000ff00f2b0 >> x12 = 0x00000000ff0118c0 >> x13 = 0x0000000000000002 >> x14 = 0x00000000ff016b70 >> x15 = 0x00000000ff003f20 >> x16 = 0x0000000000000044 >> x17 = 0x00000000ff010430 >> x18 = 0x0000000000000e3c >> x19 = 0x0000000000000000 >> More error log please refer to attachment. >> >> My question is, >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. >> >> Appreciate your help. >> >> BRs， >> Bin Wu >> > -- > 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

6 years, 1 month

1
0
0 0

Re: [TF-A] Event Log for Measured Boot

by Soby Mathew

My view is that smaller patches are easier to review and we should try to break up the patches to logical chucks where possible. I haven't taken a look at the patches myself but I am sure there will be ways to break it up for ease of review. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu > Krishnamurthy via TF-A > Sent: 20 April 2020 18:09 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Event Log for Measured Boot > > Fair enough. I have no doubt it was tested. It is just extremely difficult to review > such patches and I disagree with your statement. > There is almost always a way to split patches up by using feature flags for > example, that will help with not breaking the build. You can test them all > together once you have all the patches. I also think it is perfectly reasonable to > say measured boot cannot be turned on until a certain commit id present. > However, if you think this is the right approach, i have no issues. > > Thanks > Raghu > > On 4/20/20 8:44 AM, Alexei Fedorov wrote: > > Hi Raghu and Varun, > > > > This patch is a complete, tested and verified reference implementation > > for FVP platform. > > Splitting it will create a set of separate non-buildable patches > > causing more complexity in following and understanding the code > > changes and dependencies. > > The whole patch with all the code present in it should be reviewed > > anyway, and the time spent will be less than the time used for > > reviewing separate patches (mass defect). > > > > Alexei > > > > ---------------------------------------------------------------------- > > -- > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> > > *Sent:* 02 April 2020 05:11 > > *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > > *Subject:* Re: [TF-A] Event Log for Measured Boot Hi Alexei, > > > > I second Varun on this. The patch is huge. I recommend breaking it up > > into multiple commits. I've reviewed it but since it is a large patch, > > it might require a few more sittings to grasp all the changes(which > > also means there may be some stupid review comments :)). > > > > -Raghu > > > > On 3/31/20 10:28 AM, Varun Wadekar via TF-A wrote: > >> Hello Alexei, > >> > >> Just curious, the patch is huge and will take some time to review. Do > >> you expect this change to be merged before the v2.3 release? > >> > >> -Varun > >> > >> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > >> *Alexei Fedorov via TF-A > >> *Sent:* Tuesday, March 31, 2020 7:19 AM > >> *To:* tf-a(a)lists.trustedfirmware.org > >> *Subject:* [TF-A] Event Log for Measured Boot > >> > >> *External email: Use caution opening links or attachments* > >> > >> Hi, > >> > >> Please review and provide your comments for the patch which adds > >> > >> Event Log generation for the Measured Boot. > >> > >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 > >> > >> Thanks. > >> > >> Alexei > >> > >> 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. > >> > >> --------------------------------------------------------------------- > >> --- This email message is for the sole use of the intended > >> recipient(s) and may contain confidential information. Any > >> unauthorized review, use, disclosure or distribution is prohibited. > >> If you are not the intended recipient, please contact the sender by > >> reply email and destroy all copies of the original message. > >> --------------------------------------------------------------------- > >> --- > >> > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years, 1 month

1
0
0 0

Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Raghu K

Nice debug! Apart from the issue you pointed out, there is also the issue with not checking the return code. The ras handler should really be checking or panic'ing if there is an unexpected error code from spm_sp_call and sdei_dispatch_event. -Raghu On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > Hi Bin Wu, > > Here's an early observation. On receiving the RAS fiq interrupt the following occurs: > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > se = get_event_entry(map); > if (!can_sdei_state_trans(se, DO_DISPATCH)) > return -1; > > p *map > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} > p *se > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. > The SDEI handler is not called in NS world and context remains unchanged. > The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > SP then exits but the EL3 context has not been setup for SP entry leading to crash. > > IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. > > Regards, > Olivier. > > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matteo Carlini via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 14 April 2020 10:41 > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey > Cc: nd > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. > > Thanks > Matteo > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of ??(??) via TF-A > Sent: 14 April 2020 06:47 > To: TF-A <tf-a-bounces(a)lists.trustedfirmware.org>; Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Hi RagHu, > > Really appreciate your help. > > I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. > The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… > > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git<https://git.linaro.org/landing-teams/working/arm/edk2.git/> tag:RD-INFRA-20191024-RC0 > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git<https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git/> tag:RD-INFRA-20191024-RC0 > > 3) What version of the kernel and sdei driver is being used? > A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. > > BRs， > Bin Wu > > ------------------原始邮件 ------------------ > 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> > 发送时间:Tue Apr 14 01:25:47 2020 > 收件人:Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > Hello, > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > I don't think it will. It is really odd that > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. > This is from looking at the upstream code quickly but it definitely > depends on the platform you are running, what version of TF-A you are > using, build options used. Is it possible that the unhandled exception > is occurring after successful handling of the DMC620 error but there is > a following issue that occurs right after, causing the crash? > From the register dump it looks like there was an Instruction abort > exception at address 0 while running in EL3. Something seems to have > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > an instruction abort at address 0. > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > See above. The answer really depends on the factors mentioned above. > > The following would be helpful to know: > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > 3) What version of the kernel and sdei driver is being used? > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > > Thanks > Raghu > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: >> Dear Friends, >> >> I am using TF-A to test RAS feature. >> When I triggered DMC620 RAS error in Linux(echo 0x123 > >> /sys/kernel/debug/sdei_ras_poison). >> BL32 will recieve >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally >> BL31 crashed. >> >> In my understanding, this 0xC4000061 should consumed by BL31, not send >> it to BL32 again. >> >> A piece of error log as below: >> >> ************************************* >> >> CperWrite - CperAddress@0xFF610064 >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 >> CperWrite - Got Error Section: Platform Memory. >> MmEntryPoint Done >> Received delegated event >> X0 : 0xC4000061 >> X1 : 0x0 >> X2 : 0x0 >> X3 : 0x0 >> Received event - 0xC4000061 on cpu 0 >> UnRecognized Event - 0xC4000061 >> Failed delegated event 0xC4000061, Status 0x2 >> Unhandled Exception in EL3. >> x30 = 0x0000000000000000 >> x0 = 0x00000000ff007e00 >> x1 = 0xfffffffffffffffe >> x2 = 0x00000000600003c0 >> x3 = 0x0000000000000000 >> x4 = 0x0000000000000000 >> x5 = 0x0000000000000000 >> x6 = 0x00000000ff015080 >> x7 = 0x0000000000000000 >> x8 = 0x00000000c4000061 >> x9 = 0x0000000000000021 >> x10 = 0x0000000000000040 >> x11 = 0x00000000ff00f2b0 >> x12 = 0x00000000ff0118c0 >> x13 = 0x0000000000000002 >> x14 = 0x00000000ff016b70 >> x15 = 0x00000000ff003f20 >> x16 = 0x0000000000000044 >> x17 = 0x00000000ff010430 >> x18 = 0x0000000000000e3c >> x19 = 0x0000000000000000 >> More error log please refer to attachment. >> >> My question is, >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. >> >> Appreciate your help. >> >> BRs， >> Bin Wu >> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Olivier.Deprez＠arm.com

Hi Bin Wu, Here's an early observation. On receiving the RAS fiq interrupt the following occurs: ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event se = get_event_entry(map); if (!can_sdei_state_trans(se, DO_DISPATCH)) return -1; p *map $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} p *se $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. The SDEI handler is not called in NS world and context remains unchanged. The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 SP then exits but the EL3 context has not been setup for SP entry leading to crash. IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matteo Carlini via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 14 April 2020 10:41 To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey Cc: nd Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. Thanks Matteo From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of ??(??) via TF-A Sent: 14 April 2020 06:47 To: TF-A <tf-a-bounces(a)lists.trustedfirmware.org>; Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hi RagHu, Really appreciate your help. I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… 1) What platform you are running on? Can this issue be reproduced outside your testing environment, perhaps on FVP or QEMU? A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. 2) What version of TF-A and StandaloneMM is being used? Preferably the commit-id, so that we can be sure we are looking at the same code. A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git<https://git.linaro.org/landing-teams/working/arm/edk2.git/> tag:RD-INFRA-20191024-RC0 edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git<https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git/> tag:RD-INFRA-20191024-RC0 3) What version of the kernel and sdei driver is being used? A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. 4) I can't tell from looking at the log but do you know if writing 0x123 to sde_ras_poison causes a DMC620 interrupt or an SError or external abort through memory access ? A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. BRs， Bin Wu ------------------原始邮件 ------------------ 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> 发送时间:Tue Apr 14 01:25:47 2020 收件人:Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hello, >>Does BL31 need to send 0xC4000061 event to BL32 again? I don't think it will. It is really odd that 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. This is from looking at the upstream code quickly but it definitely depends on the platform you are running, what version of TF-A you are using, build options used. Is it possible that the unhandled exception is occurring after successful handling of the DMC620 error but there is a following issue that occurs right after, causing the crash? From the register dump it looks like there was an Instruction abort exception at address 0 while running in EL3. Something seems to have gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get an instruction abort at address 0. >>Does current TF-A support to run RAS test? It seems BL31 will crash. See above. The answer really depends on the factors mentioned above. The following would be helpful to know: 1) What platform you are running on? Can this issue be reproduced outside your testing environment, perhaps on FVP or QEMU? 2) What version of TF-A and StandaloneMM is being used? Preferably the commit-id, so that we can be sure we are looking at the same code. 3) What version of the kernel and sdei driver is being used? 4) I can't tell from looking at the log but do you know if writing 0x123 to sde_ras_poison causes a DMC620 interrupt or an SError or external abort through memory access ? Thanks Raghu On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: > Dear Friends, > > I am using TF-A to test RAS feature. > When I triggered DMC620 RAS error in Linux(echo 0x123 > > /sys/kernel/debug/sdei_ras_poison). > BL32 will recieve > UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally > BL31 crashed. > > In my understanding, this 0xC4000061 should consumed by BL31, not send > it to BL32 again. > > A piece of error log as below: > > ************************************* > > CperWrite - CperAddress@0xFF610064 > CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 > CperWrite - Got Error Section: Platform Memory. > MmEntryPoint Done > Received delegated event > X0 : 0xC4000061 > X1 : 0x0 > X2 : 0x0 > X3 : 0x0 > Received event - 0xC4000061 on cpu 0 > UnRecognized Event - 0xC4000061 > Failed delegated event 0xC4000061, Status 0x2 > Unhandled Exception in EL3. > x30 = 0x0000000000000000 > x0 = 0x00000000ff007e00 > x1 = 0xfffffffffffffffe > x2 = 0x00000000600003c0 > x3 = 0x0000000000000000 > x4 = 0x0000000000000000 > x5 = 0x0000000000000000 > x6 = 0x00000000ff015080 > x7 = 0x0000000000000000 > x8 = 0x00000000c4000061 > x9 = 0x0000000000000021 > x10 = 0x0000000000000040 > x11 = 0x00000000ff00f2b0 > x12 = 0x00000000ff0118c0 > x13 = 0x0000000000000002 > x14 = 0x00000000ff016b70 > x15 = 0x00000000ff003f20 > x16 = 0x0000000000000044 > x17 = 0x00000000ff010430 > x18 = 0x0000000000000e3c > x19 = 0x0000000000000000 > More error log please refer to attachment. > > My question is, > 1. Does BL31 need to send 0xC4000061 event to BL32 again? > 2. Does current TF-A support to run RAS test? It seems BL31 will crash. > > Appreciate your help. > > BRs， > Bin Wu > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Trusted Firmware-A & TF-A tests version 2.3 is now available

by Bipin Ravi

Hi all, Trusted Firmware-A and TF-A tests version 2.3 is now available and can be found here: TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.3 TF-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.3 Please refer to the readme and change log for further information. Thanks & best regards, [cid:image001.jpg@01D6170F.64702DF0] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Bipin.Ravi@arm.com> | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

6 years, 1 month

1
0
0 0

Re: [TF-A] Event Log for Measured Boot

by Alexei Fedorov

Hi Raghu and Varun, This patch is a complete, tested and verified reference implementation for FVP platform. Splitting it will create a set of separate non-buildable patches causing more complexity in following and understanding the code changes and dependencies. The whole patch with all the code present in it should be reviewed anyway, and the time spent will be less than the time used for reviewing separate patches (mass defect). Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 02 April 2020 05:11 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Event Log for Measured Boot Hi Alexei, I second Varun on this. The patch is huge. I recommend breaking it up into multiple commits. I've reviewed it but since it is a large patch, it might require a few more sittings to grasp all the changes(which also means there may be some stupid review comments :)). -Raghu On 3/31/20 10:28 AM, Varun Wadekar via TF-A wrote: > Hello Alexei, > > Just curious, the patch is huge and will take some time to review. Do > you expect this change to be merged before the v2.3 release? > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Alexei Fedorov via TF-A > *Sent:* Tuesday, March 31, 2020 7:19 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Event Log for Measured Boot > > *External email: Use caution opening links or attachments* > > Hi, > > Please review and provide your comments for the patch which adds > > Event Log generation for the Measured Boot. > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 > > Thanks. > > Alexei > > 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. > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

6 years, 1 month

2
1
0 0

Re: [TF-A] [RFC] isolation between runtime BL33 services and OS

by Olivier.Deprez＠arm.com

Hi, If buffers are to be consumed by NWd only, it's probably better to contain the isolation at NS-EL2 (through Stage-2 MMU mapping). Though from your statements I'm not clear if you wish to use an hypervisor, or not? If yes, which implementation or kind do you want to use? If not, I wonder if you could re-use OS facilities like shared mem with different permissions for two child processes (might be tricky)? I don't think execute-only regions exist in Cortex-A (unless implementing additional hardware). If executable it's probably also readable. Maybe you meant execute-never? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [RFC] isolation between runtime BL33 services and OS Hi, I am trying to identify a mechanism to enforce a form of two-way isolation between BL33 runtime services in OS, for instance: - a pair of 2MB areas that could be RO by one entity and RW by the other - an execute only BL33 2MB area? This is similar to hypervisor except it only deals with memory, no vCPU, no GIC virtualization... Could EL3 or EL2 install protective mappings ? BL33 could ask either EL2 hypervisor or SecureMonitor to actually install them. Cordially, FF -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

[RFC] isolation between runtime BL33 services and OS

by François Ozog

Hi, I am trying to identify a mechanism to enforce a form of two-way isolation between BL33 runtime services in OS, for instance: - a pair of 2MB areas that could be RO by one entity and RW by the other - an execute only BL33 2MB area? This is similar to hypervisor except it only deals with memory, no vCPU, no GIC virtualization... Could EL3 or EL2 install protective mappings ? BL33 could ask either EL2 hypervisor or SecureMonitor to actually install them. Cordially, FF

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A