April 2020 - TF-A - lists.trustedfirmware.org

Re: [TF-A] fconf: Validating config data

by Sandrine Bailleux

Hi Raghu and Louis, On 4/7/20 12:14 PM, Louis Mayencourt via TF-A wrote: > I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and > should lead to the same behavior. > > A mandatory property miss or a hit with a structurally incorrect node > means that the DTB doesn't follow the provided binding document. Such a > DTB shouldn't be considered as valid and should trigger a build failure > and/or a code panic. That's what still confuses me... Agree on cases 2 and 3 triggering a build failure if possible, but not a code panic. A code panic stays in a release build. With what we've been discussing so far, it would seem more appropriate to me to have debug assertions to catch cases 2 and 3. These debug assertions can help catching structural problems in the DTB during the development phase and can be eliminated for a production build, leaving no checks whatsoever in the code. This is the strategy we've been using so far in TF-A. For lots of platform interfaces, the generic code includes debug assertions to check the correct implementation of these interfaces by platform integrators. For example, checking the range of their return values. I would say this is deeply embedded into the threat model TF-A uses today. See https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline… On one hand, it makes sense to me. On the other hand, I take Raghu's point that it would be unrealistic to assume that 100% of code has been covered by tests. This is very hard to achieve in practice, especially to cover all error cases ; thus, it seems utopian to assume that all debug assertions have been exercised during development and can be safely removed. TF-A does provide a way to keep debug assertions in a release build (using the ENABLE_ASSERTIONS build flag) if platform integrators judge they would rather keep them but this is not the default behaviour. Regards, Sandrine

4 years, 6 months

3
4
0 0

Re: [TF-A] Proposal for Measured Boot Implementation

by Vivek Prasad

Hello Stuart, Alexei, Chiming-in here on Ampere's behalf... We analysed this proposal internally. And we see a number issues with this, some of which was already raised by Raghu in the previous threads. Here is a summary of the main issues that we see. * Only supporting mbedtls, and this is fixed config at compile time. * We propose that there should be a variable for the algorithm to be used, which can be setup at initialization time. * This solution relies on taking the hash directly from the digest as the measurement, instead of the computed hash. This is not safe, especially considering measured boot may use a different hash bank, so digest hash may not be correct/valid. * Only measuring the BL2 image, per the ARM SBSG we must be measuring and logging *all* images/boot phases * BL31 * BL32 (all secure partitions) * BL33 (UEFI or any other non-secure boot loader) * Once we ERET into BL33, the measure boot flow continues and is owned by that boot loader * Only see support for PCR0, any/all unsigned config data must be logged to PCR1. * Passing PCRs to non-secure software before logging is not compliant with TCG Static-Root-of-Trust Measurement (SRTM) requirements * It was discussed before in separate conversations… especially in systems where you are talked about two different signing domains where BL33 is a different trust/signing domain. * BL33 should only do hash-log-extend… there is no need for BL33 to be aware of the current PCR value (beyond what is provided in the boot event log). * Based on comments on the mail thread, there seem to be bad assumptions/expectations around TPM accessibility from non-secure world. * Expecting SPI/I2C TPMs to be directly accessed from non-secure world instead of abstracting hardware details via the TCG CRB interface (which has been already standardized as the defacto mechanism for ARM on past mobile, client, and server solutions). * CRB will "just work" for Aptio/EDK2/Linux/Windows/Hyper-V/VMWare * NOTE: This goes back to what is a “productizable” TPM solution. We want it to be turn-key solution for customers without having to support/develop proprietary drivers. -Vivek/Harb

4 years, 6 months

3
3
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.

4 years, 6 months

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

4 years, 6 months

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

4 years, 6 months

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.

4 years, 6 months

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.

4 years, 6 months

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.

4 years, 7 months

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.

4 years, 7 months

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. >

4 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A April 2020