- TF-A - lists.trustedfirmware.org

by Samuel Holland

Hi, On 5/12/20 1:41 PM, Varun Wadekar via TF-A wrote: > While reviewing all the compiler flags used by TF-A, we couldn’t find > information for the following options in the GCC manual [1] > > * --fatal-warnings > (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) Options passed to -Wa are assembler options, not compiler options. That one is documented here: https://sourceware.org/binutils/docs/as/W.html > * -fno-stack-protector > (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) This is the negative version of -fstack-protector, needed on compilers configured with --enable-default-ssp: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Instrumentation-Options.html#… They are both valid. Regards, Samuel

5 years, 9 months

1
0
0 0

GCC compiler flags

by Varun Wadekar

Hello, While reviewing all the compiler flags used by TF-A, we couldn't find information for the following options in the GCC manual [1] * --fatal-warnings (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) * -fno-stack-protector (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) Can someone please help me understand if these options are still valid? Thanks. [1] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Option-Index.html#Option-Index ----------------------------------------------------------------------------------- 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. -----------------------------------------------------------------------------------

5 years, 9 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > 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! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

5 years, 10 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 358027: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 358027: Insecure data handling (TAINTED_SCALAR) /common/fdt_wrappers.c: 295 in fdt_get_reg_props_by_name() 289 290 index = fdt_stringlist_search(dtb, node, "reg-names", name); 291 if (index < 0) { 292 return index; 293 } 294 >>> CID 358027: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "index" to a tainted sink. 295 return fdt_get_reg_props_by_index(dtb, node, index, base, size); 296 } 297 298 /******************************************************************************* 299 * This function gets the stdout path node. 300 * It reads the value indicated inside the device tree. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 10 months

1
0
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

5 years, 10 months

3
3
0 0

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

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

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.

5 years, 10 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

5 years, 10 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

5 years, 10 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.

5 years, 10 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.

5 years, 10 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.

5 years, 10 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.

5 years, 10 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. >

5 years, 10 months

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.

5 years, 10 months

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

5 years, 10 months

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.

5 years, 10 months

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.

5 years, 10 months

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.

5 years, 10 months

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.

5 years, 10 months

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

5 years, 10 months

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.

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

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.

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

1
0
0 0

TrustedFirmware's Hafnium mailing list

by Olivier Deprez

Hi, As part of integrating Hafnium within Trusted Firmware projects, a new mailing list has been created: https://lists.trustedfirmware.org/mailman/listinfo/hafnium You can register this list to participate to Hafnium in general, and coming S-EL2 firmware design discussions. Regards, Olivier.

5 years, 10 months

1
0
0 0

Re: [TF-A] Design proposal: firmware debugfs interface

by Olivier Deprez

Hi, To complement the DebugFS design proposal document, here is a corresponding TF-A patchset: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2422 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2431 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2432 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2423 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2421 An associated TFTF test case illustrates the usage: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/2433 Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 25 October 2019 15:30 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Design proposal: firmware debugfs interface Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. 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

5 years, 10 months

1
1
0 0

Re: [TF-A] Linux as BL33

by Ash Wilding

Hi @François<mailto:francois.ozog@linaro.org>, <quote> Now, I changed U-Boot to Image, added code to ensure arg0 is 0 (DTB) but Linux does not start (zero printk visible). I don't find kernel text base anymore, may be it disappeared: any suggestion to get the kernel start when loaded at 64KB offset? the kernel image with embedded initrd is 10MB, SRAM is at 64MB so there should be enough space to decompress initrd... </quote> I recommend reading through the arm64 Linux booting requirements if you haven’t already; you’ll need to ensure all of those conditions are met before entering the kernel [1]. For example have you correctly set text_offset in the image header? <quote> u32 code0; /* Executable code */ u32 code1; /* Executable code */ u64 text_offset; /* Image load offset, little endian */ u64 image_size; /* Effective Image size, little endian */ u64 flags; /* kernel flags, little endian */ u64 res2 = 0; /* reserved */ u64 res3 = 0; /* reserved */ u64 res4 = 0; /* reserved */ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ u32 res5; /* reserved (used for PE COFF offset) */ </quote> <quote> The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there. </quote> Kind regards, Ash. [1] https://elixir.bootlin.com/linux/latest/source/Documentation/arm64/booting.… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

2
2
0 0

Re: [TF-A] sp select in atf

by Ash Wilding

Hi Feng, This is standard practice for operating systems, hypervisors, and firmware running on Armv8-A systems. A key distinction between SPSel,#0 and SPSel,#1 is that you can tell which stack pointer you were using when you took an exception as they correspond to different offsets in the vector table. Often times, taking an exception from the same EL when using SPSel,#0 is non-terminal whereas taking an exception from the same EL when already using SPSel,#1 is considered terminal. Take for example the scenario where your operating system, hypervisor, or firmware is running some task/thread code at EL1/EL2/EL3 and runs out of stack space, triggering a translation fault and attempting to stack some data (we’ll probably be using unmapped guard pages at the stack boundaries). The first thing the exception handler will try to do is stack the GPRs. If the reason you took the exception is because the stack pointed to by SP_EL1/2/3 has itself overflowed, this attempt to stack the GPRs will itself cause a translation fault and you’ll get stuck in a recursive exception. In contrast, if the reason you took the exception is because the stack pointed to by SP_EL0 has overflowed, the exception handler will successfully stack the GPRs to the SP_EL1/2/3 stack and be able to diagnose + log what went wrong before rebooting gracefully. Hope that helps, Ash. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Chen Feng <puck.chen(a)hisilicon.com> Date: Friday, 17 April 2020 at 09:02 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, Alexei Fedorov <Alexei.Fedorov(a)arm.com>, Yatharth Kochar <Yatharth.Kochar(a)arm.com>, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> Cc: "puck.chen(a)hisilicon.com" <puck.chen(a)hisilicon.com>, "lizhong11(a)hisilicon.com" <lizhong11(a)hisilicon.com> Subject: [TF-A] sp select in atf Hello all, I see the atf use different sp, and special for smc64 it use the sp_el0. So for the unhandled-exception handler, it must switch to sp_el0 to do the back-trace-dump. Since it default used sp_el3 when exception happen. My question here is why using different sp in atf code? Just use the sp_el3 for all scenes seems more simpler. Cheers, - feng -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-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.

5 years, 10 months

2
1
0 0

sp select in atf

by Chen Feng

Hello all, I see the atf use different sp, and special for smc64 it use the sp_el0. So for the unhandled-exception handler, it must switch to sp_el0 to do the back-trace-dump. Since it default used sp_el3 when exception happen. My question here is why using different sp in atf code? Just use the sp_el3 for all scenes seems more simpler. Cheers, - feng

5 years, 10 months

1
0
0 0

Re: [TF-A] Linux as BL33

by Manish Pandey2

As of now ARM_LINUX_KERNEL_AS_BL33 is only supported when RESET_TO_BL31=1, along with it you need to pass PRELOADED_BL33_BASE as well as ARM_PRELOADED_DTB_BASE. AFAIK This feature is not tested for platforms which uses all the BL(1/2/31) stages from TF-A . The most likely reason for this is loading and authentication of Linux Image. BL2 which is responsible for loading of various images, does not have support to load linux image. With platforms having RESET_TO_BL31, TF-A relies on prior loader which loads kernel and device tree blobs at respective address. In short, if your platform has RESET_TO_BL31=1, it will be quite easy else you need to understand the BL2 loading mechanism and see if you can extend it for loading Linux and DTB. Kernel Output format zImage/Image should work. Hope this helps! ________________________________ 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: 15 April 2020 13:31 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linux as BL33 I want to use Linux as BL33 on a Marvell Macchiatobin. Currently I have the successful boot flow: TFA (mainline v2.2) -> U-Boot (Mainline 2020.04rc5) -> Kernel (5.6.3) with U-root initrd (6.0.0, https://github.com/u-root/u-root ) -> Ubuntu 19.10 The 5.6.3 "intermediary" kernel is 5.5MB uncompressed , u-root initrd is 3.5MB compressed (some form of golang based busybox). I was pointed to the ARM_LINUX_KERNEL_AS_BL33 option which is not supported on the Macchiatobin. It does not look too difficult to add, but I'd like to have some feedback/guidance on how to do it: - how to add the option to the TFA platform - how to generate a usable kernel (compile options? non relocatable kernel? output format, i.e. Image, zImage, uImage...) Thanks for your help -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.

5 years, 10 months

2
3
0 0

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

by Vivek Prasad

+Harb ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Vivek Prasad via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: Thursday, April 16, 2020 10:19 AM To: Stuart Yoder <stuart.yoder(a)arm.com>; Alexei Fedorov <Alexei.Fedorov(a)arm.com>; tf-a <tf-a(a)lists.trustedfirmware.org>; Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Cc: Loc Ho <loc.ho(a)amperecomputing.com>; Vivek Kumar <vivek(a)amperecomputing.com>; Benjamin Chaffin <bchaffin(a)amperecomputing.com>; Ard Biesheuvel <Ard.Biesheuvel(a)arm.com>; Mohamad Ammar <moe(a)amperecomputing.com>; Charles Garcia-Tobin <Charles.Garcia-Tobin(a)arm.com> Subject: Re: [TF-A] Proposal for Measured Boot Implementation 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

5 years, 10 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, Thanks to all who have commented on this proposal so far. I've edited the original document to try and incorporate all feedback gathered so far (through the TSC meeting, this email thread and the TF-A tech call). Please have another look and flag anything I might have missed: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… The major changes are: == Removed concept of self-review == This is proving too controversial, several people do not want to allow self-review. Roles of maintainer and code owner are still cumulative but cannot be both exercised for the same patch. The exact method of dealing with review bottleneck is still to be decided. In addition to the current proposal of increasing the maintainers pool, the most popular alternatives mentioned so far are: - Set a minimum wait time for feedback before a patch can be merged without any further delay. - Mandate distinct reviewers for a patch. == Enhanced the section "Patch contribution Guidelines" == Mentioned that patches should be small, on-topic, with comprehensive commit messages. == Added a note about how to deal with disagreement == If reviewers cannot find a common ground, the proposal is to call out a 3rd-party maintainer. == Removed "out-of-date" platform state == Squashed it into "limited support" to reduce the number of states. == Removed "orphan" state from platform support life cycle == This concept is orthogonal to the level of functionality. Added a note in the "Code Owner" section instead. == Per-project guidelines as a complementary document == Added a list of things that it would typically cover. == Added requirement on fully supported platforms to document the features they support == == Added todo mentioning that the proposal might cover branching strategies in the future == The full diff may be seen here: https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5 This proposal is still open for discussion at this stage and further feedback is most welcome! Regards, Sandrine

5 years, 10 months

1
0
0 0

Linux as BL33

by François Ozog

I want to use Linux as BL33 on a Marvell Macchiatobin. Currently I have the successful boot flow: TFA (mainline v2.2) -> U-Boot (Mainline 2020.04rc5) -> Kernel (5.6.3) with U-root initrd (6.0.0, https://github.com/u-root/u-root ) -> Ubuntu 19.10 The 5.6.3 "intermediary" kernel is 5.5MB uncompressed , u-root initrd is 3.5MB compressed (some form of golang based busybox). I was pointed to the ARM_LINUX_KERNEL_AS_BL33 option which is not supported on the Macchiatobin. It does not look too difficult to add, but I'd like to have some feedback/guidance on how to do it: - how to add the option to the TFA platform - how to generate a usable kernel (compile options? non relocatable kernel? output format, i.e. Image, zImage, uImage...) Thanks for your help -FF

5 years, 10 months

1
0
0 0

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

by Matteo Carlini

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

5 years, 10 months

1
0
0 0

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

by 吴斌(郅隆)

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 <tf-a-bounces(a)lists.trustedfirmware.org> 发送时间:Tue Apr 14 01:25:47 2020 收件人:Raghu Krishnamurthy via TF-A <tf-a(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 https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 10 months

1
0
0 0

Re: [TF-A] BRANCH_PROTECTION

by Alexei Fedorov

Hi Varun, 1. The value of '1' sets ‘standard’ type of BP which according to GCC documentation: "turns on all types of branch protection features. If a feature has additional tuning options, then ‘standard’ sets it to its standard level. " It equals to "bti+pac-ret". 2. Yes. See above and use option value of '1'. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 10 April 2020 19:28 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; Anthony Zhou <anzhou(a)nvidia.com> Subject: Re: [TF-A] BRANCH_PROTECTION Hello, Can someone please help clarify? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, April 7, 2020 9:58 PM To: tf-a(a)lists.trustedfirmware.org Cc: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; Anthony Zhou <anzhou(a)nvidia.com> Subject: [TF-A] BRANCH_PROTECTION External email: Use caution opening links or attachments Hello, Can someone please help me understand if 1. a ‘value’ of ‘1’ for BRANCH_PROTECTION covers the PAuth protection provided by a value of ‘2’ and/or ‘3’? 2. there is a way to enable BTI and “pac-ret” at the same time? The docs provide this information. <snip> - ``BRANCH_PROTECTION``: Numeric value to enable ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification support for TF-A BL images themselves. If enabled, it is needed to use a compiler that supports the option ``-mbranch-protection``. Selects the branch protection features to use: - 0: Default value turns off all types of branch protection - 1: Enables all types of branch protection features - 2: Return address signing to its standard level - 3: Extend the signing to include leaf functions The table below summarizes ``BRANCH_PROTECTION`` values, GCC compilation options and resulting PAuth/BTI<https://tegra-sw-opengrok.nvidia.com/source/s?path=PAuth/BTI&project=stage-…> features. +-------+--------------+-------+-----+ | Value | GCC option | PAuth | BTI | +=======+==============+=======+=====+ | 0 | none | N | N | +-------+--------------+-------+-----+ | 1 | standard | Y | Y | +-------+--------------+-------+-----+ | 2 | pac-ret | Y | N | +-------+--------------+-------+-----+ | 3 | pac-ret+leaf | Y | N | +-------+--------------+-------+-----+ This option defaults to 0 and this is an experimental feature. Note that Pointer Authentication is enabled for Non-secure world irrespective of the value of this option if the CPU supports it. <snip> Thanks, Varun ________________________________ 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. ________________________________ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

2
1
0 0

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

by Raghu Krishnamurthy

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 >

5 years, 10 months

1
0
0 0

[RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by 吴斌(郅隆)

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

5 years, 10 months

1
0
0 0

Re: [TF-A] BRANCH_PROTECTION

by Varun Wadekar

Hello, Can someone please help clarify? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, April 7, 2020 9:58 PM To: tf-a(a)lists.trustedfirmware.org Cc: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; Anthony Zhou <anzhou(a)nvidia.com> Subject: [TF-A] BRANCH_PROTECTION External email: Use caution opening links or attachments Hello, Can someone please help me understand if 1. a 'value' of '1' for BRANCH_PROTECTION covers the PAuth protection provided by a value of '2' and/or '3'? 2. there is a way to enable BTI and "pac-ret" at the same time? The docs provide this information. <snip> - ``BRANCH_PROTECTION``: Numeric value to enable ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification support for TF-A BL images themselves. If enabled, it is needed to use a compiler that supports the option ``-mbranch-protection``. Selects the branch protection features to use: - 0: Default value turns off all types of branch protection - 1: Enables all types of branch protection features - 2: Return address signing to its standard level - 3: Extend the signing to include leaf functions The table below summarizes ``BRANCH_PROTECTION`` values, GCC compilation options and resulting PAuth/BTI<https://tegra-sw-opengrok.nvidia.com/source/s?path=PAuth/BTI&project=stage-…> features. +-------+--------------+-------+-----+ | Value | GCC option | PAuth | BTI | +=======+==============+=======+=====+ | 0 | none | N | N | +-------+--------------+-------+-----+ | 1 | standard | Y | Y | +-------+--------------+-------+-----+ | 2 | pac-ret | Y | N | +-------+--------------+-------+-----+ | 3 | pac-ret+leaf | Y | N | +-------+--------------+-------+-----+ This option defaults to 0 and this is an experimental feature. Note that Pointer Authentication is enabled for Non-secure world irrespective of the value of this option if the CPU supports it. <snip> Thanks, Varun ________________________________ 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. ________________________________

5 years, 11 months

1
0
0 0

Trusted Firmware-A 2.3 release candidate tags created

by Bipin Ravi

All, We have applied the release candidate tags(v2.3-rc0<https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.3-rc0>) to the TF-A source and TF-A tests trees as part of the upcoming TF-A v2.3 release. Please use these tags to perform any platform specific tests planned. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ https://git.trustedfirmware.org/TF-A/tf-a-tests.git/ Thanks & best regards, [cid:image001.jpg@01D60DB5.48537900] Bipin Ravi | Principal Design Enginee Bipin.ravi(a)arm.com<mailto:Bipin.ravi@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

5 years, 11 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 355490: Uninitialized variables (UNINIT) /plat/brcm/board/stingray/src/paxb.c: 516 in pcie_cores_init() ________________________________________________________________________________________________________ *** CID 355490: Uninitialized variables (UNINIT) /plat/brcm/board/stingray/src/paxb.c: 516 in pcie_cores_init() 510 511 pcie_core_soft_reset(core_idx); 512 513 VERBOSE("PCIe core %u is powered up\n", core_idx); 514 } 515 >>> CID 355490: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 516 return ret; 517 } 518 519 void paxb_rc_cfg_write(unsigned int core_idx, unsigned int where, 520 uint32_t val) 521 { ** CID 355489: Control flow issues (NO_EFFECT) /plat/brcm/board/stingray/src/bl2_setup.c: 685 in plat_bcm_bl2_plat_arch_setup() ________________________________________________________________________________________________________ *** CID 355489: Control flow issues (NO_EFFECT) /plat/brcm/board/stingray/src/bl2_setup.c: 685 in plat_bcm_bl2_plat_arch_setup() 679 EMMC_ERASE_PARTITION); 680 #endif 681 682 bcm_board_detect(); 683 #ifdef DRIVER_EMMC_ENABLE 684 /* Initialize the card, if it is not */ >>> CID 355489: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "bcm_emmc_init(true) < 0U". 685 if (bcm_emmc_init(true) < 0) 686 WARN("eMMC Card Initialization Failed!!!\n"); 687 #endif 688 689 #if BL2_TEST_I2C 690 i2c_test(); ** CID 355488: (VARARGS) /plat/brcm/board/common/bcm_elog.c: 251 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 253 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 241 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 234 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 223 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 239 in bcm_elog() ________________________________________________________________________________________________________ *** CID 355488: (VARARGS) /plat/brcm/board/common/bcm_elog.c: 251 in bcm_elog() 245 case 'l': 246 bit64 = 1; 247 fmt++; 248 goto loop; 249 case 'u': 250 if (bit64) >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 251 unum = va_arg(args, uint64_t); 252 else 253 unum = va_arg(args, uint32_t); 254 255 elog_unsigned_num(elog, unum, 10); 256 break; /plat/brcm/board/common/bcm_elog.c: 253 in bcm_elog() 247 fmt++; 248 goto loop; 249 case 'u': 250 if (bit64) 251 unum = va_arg(args, uint64_t); 252 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 253 unum = va_arg(args, uint32_t); 254 255 elog_unsigned_num(elog, unum, 10); 256 break; 257 default: 258 /* Exit on any other format specifier */ /plat/brcm/board/common/bcm_elog.c: 241 in bcm_elog() 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) 239 unum = va_arg(args, uint64_t); 240 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 241 unum = va_arg(args, uint32_t); 242 243 elog_unsigned_num(elog, unum, 16); 244 break; 245 case 'l': 246 bit64 = 1; /plat/brcm/board/common/bcm_elog.c: 234 in bcm_elog() 228 } else 229 unum = (unsigned long)num; 230 231 elog_unsigned_num(elog, unum, 10); 232 break; 233 case 's': >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 234 str = va_arg(args, char *); 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) 239 unum = va_arg(args, uint64_t); /plat/brcm/board/common/bcm_elog.c: 223 in bcm_elog() 217 switch (*fmt) { 218 case 'i': /* Fall through to next one */ 219 case 'd': 220 if (bit64) 221 num = va_arg(args, int64_t); 222 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 223 num = va_arg(args, int32_t); 224 225 if (num < 0) { 226 elog_putchar(elog, '-'); 227 unum = (unsigned long)-num; 228 } else /plat/brcm/board/common/bcm_elog.c: 239 in bcm_elog() 233 case 's': 234 str = va_arg(args, char *); 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 239 unum = va_arg(args, uint64_t); 240 else 241 unum = va_arg(args, uint32_t); 242 243 elog_unsigned_num(elog, unum, 16); 244 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 11 months

1
0
0 0

BRANCH_PROTECTION

by Varun Wadekar

Hello, Can someone please help me understand if 1. a 'value' of '1' for BRANCH_PROTECTION covers the PAuth protection provided by a value of '2' and/or '3'? 2. there is a way to enable BTI and "pac-ret" at the same time? The docs provide this information. <snip> - ``BRANCH_PROTECTION``: Numeric value to enable ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification support for TF-A BL images themselves. If enabled, it is needed to use a compiler that supports the option ``-mbranch-protection``. Selects the branch protection features to use: - 0: Default value turns off all types of branch protection - 1: Enables all types of branch protection features - 2: Return address signing to its standard level - 3: Extend the signing to include leaf functions The table below summarizes ``BRANCH_PROTECTION`` values, GCC compilation options and resulting PAuth/BTI<https://tegra-sw-opengrok.nvidia.com/source/s?path=PAuth/BTI&project=stage-…> features. +-------+--------------+-------+-----+ | Value | GCC option | PAuth | BTI | +=======+==============+=======+=====+ | 0 | none | N | N | +-------+--------------+-------+-----+ | 1 | standard | Y | Y | +-------+--------------+-------+-----+ | 2 | pac-ret | Y | N | +-------+--------------+-------+-----+ | 3 | pac-ret+leaf | Y | N | +-------+--------------+-------+-----+ This option defaults to 0 and this is an experimental feature. Note that Pointer Authentication is enabled for Non-secure world irrespective of the value of this option if the CPU supports it. <snip> Thanks, Varun ----------------------------------------------------------------------------------- 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. -----------------------------------------------------------------------------------

5 years, 11 months

1
0
0 0

Re: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

I realise non TF-A people may not have access to session conference details. These can be found here: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000330.html From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Tuesday, 7 April 2020 at 18:10 To: tf-a <tf-a(a)lists.trustedfirmware.org> Cc: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, "op-tee(a)linaro.org" <op-tee(a)linaro.org> Subject: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). 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. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 11 months

1
0
0 0

TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). 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. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * 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.

5 years, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A