- TF-A - lists.trustedfirmware.org

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, 6 months

2
5
0 0

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

by Manish Badarkhe

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

5 years, 6 months

2
1
0 0

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

by François Ozog

This event has been changed. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 2 weeks from 18:00 to 19:00 on Thursday from Thu 7 May to Thu 30 Jul Central European Time - Paris (changed) Where: Zoom Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 6 months

1
0
0 0

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

by Olivier Deprez

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

5 years, 6 months

3
6
0 0

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

by Manish Badarkhe

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

5 years, 6 months

3
6
0 0

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

by Manish Badarkhe

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

5 years, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 months

1
0
0 0

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

by Sandrine Bailleux

Hi Joakim, On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote: > Hi Sandrine, > > On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote: >> Hi Joakim, >> >> On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: >>> How that works in practice is that all OP-TEE maintainers are adding >>> their "Tested-by" (see example [2]) tag for the platform they maintain >>> when we're doing a release. If there are platforms with no "Tested-by" >>> tag, then they simply end up with the "last known version". >> >> I think that's a very good idea! >> > The "Tested-by" part for OP-TEE releases has been working pretty good, > not sure how scalable it is the long run though. To give some more > info regarding the "last known version", we even at one point had some > stop-light for that. I.e. if a maintainer missed testing a release once, > then it became "orange". If missed twice, then it became "red" and we > showed last know supported version. But we dropped that idea a short > while after introducing it. May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info). >>> However, to keep that up-to-date, it requires some discipline from the >>> people maintaining such a table ... something that we in the OP-TEE >>> project haven't been very good at :) >> >> Can't this be automated, such that it doesn't need to be manually kept >> up-to-date? I imagine we could have some tools generating the platform >> support table out of such a commit message. >> > Indeed it could, it's just a matter of doing some scripting if one > doesn't want to do it manually. I already have Python scripts pulling > all tags from GitHub pull requests. But there are of course several > other ways how one could pull that kind of information. Regards, Sandrine

5 years, 6 months

2
1
0 0

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

by Sandrine Bailleux

Hi Erik, On 4/1/20 9:24 PM, Shreve, Erik via TF-A wrote: > Sandrine, > > To clarify on functionality vs. support. I listed out a support life cycle consisting of the following states: > Fully Supported > Orphan > Out of Date > Deprecated > These states are intended to have nothing to do with functionality, but only the support offered for the functionality that currently exists for a platform. > > I think I may have confused things when I listed "Functional Support" as the heading to represent "Functionality." > I'm proposing that the supported "Functionality" should be documented in a standard way (within a project) for every platform. > > I do agree this could be burdensome to keep up with. But that is why I suggested that the project's feature list be versioned. The platform's supported feature list document would reference the version of the project feature list used. Platform maintainers then don' t have to continuously update the document. But it will be clear how long it has been since they did update and thus what information may be missing. Versioning the feature list document is also why I mentioned that the project version number may want to adopt a version number scheme where feature changes are represented by a certain part of the version number. For example Semantic Versioning 2.0.0: https://semver.org/. Hope that clarifies the intent? For implementation of this I'm imagining each project could create a supported_feature_list.rst file and each platform would copy that file into their platform doc folder and fill it in. I'm not saying that approach would be required at tf.org level, just sharing to further illustrate. > > That said, perhaps the implementation details for a project would not warrant such a document per platform? My primary concern around this is misuse/misconfiguration. If a platform doesn't support a feature or configuration it may not be obvious to a user unless an error is generated at build or run-time. OK, I think I get the idea now, thanks for the explanations. This looks reasonable to me. The idea of keeping a project's feature list being mirrored and filled in per platform sounds like something we would want to enforce at the tf.org level IMO. At the same time, this could also be handled at the build system level as you pointed out, or more precisely by the configuration manager. I am thinking about the Linux kernel, where support for a particular feature is handled (and documented) through the KConfig system. This might be a more scalable approach. And it doesn't prevent us from also auto-generating some feature list out of the Kconfig files for making this information more accessible to users. > My secondary concern is being able to consistently track tickets/bugs with features. Thus, I'm recommending that the features on that list be used with the ticket/issue system by feature name. This would allow users to find all bugs for Feature X on Platform Y in Project Z. > Related to that, when I mentioned "tags." I wasn't thinking of Git tags, but "labels" in the ticket/issue tracking system(s). Different systems work differently for labeling/categorizing issues, but the goal is to provide a consistent way (per project) to find issues related to a feature on a platform. > > If requiring a feature list it is too much at the tf.org level then I'll be satisfied to push for that kind of documentation in the projects or platforms I'm involved in if/as appropriate. Yes, good point, I think it would be desirable to be able to tie tickets to some specific platform/feature/version. And I think it makes sense to unify this across tf.org projects. > Regarding the other conversational tidbits: > > Thanks for pointing out that the original proposal does say "builds all configurations supported by this platform" under "Fully Supported." I can see the intention here now. Substituting "features" for "configurations" would broaden the meaning a bit. OK, I will change the wording, thanks for the suggestion. > You said: "I am starting to think that we need a list of items to be defined per project." > Yes, this sounds like a great idea. > > My original mention of wanting a "stronger standard put forth for platform documentation" was a response to seeing "Limited Support" in the original proposal allowing documentation to fall out of date. > > > Hope that clarifies some of my thoughts. If not, I'm happy to continue the discussion. Thanks again for taking feedback! > > Erik Shreve, PSEM > Software Security Engineer & Architect (CMCU Platform Development) > > -----Original Message----- > From: Sandrine Bailleux [mailto:sandrine.bailleux@arm.com] > Sent: Wednesday, April 01, 2020 4:18 AM > To: Shreve, Erik; tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org > Cc: nd(a)arm.com > Subject: Re: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects > > Hello Erik, > > Thanks for the feedback. > > On 3/26/20 3:37 PM, Shreve, Erik wrote: >> Sandrine, >> >> Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. >> >> As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. >> I'd like to see these split out. > > Yes, you are the second person to mention that and I agree with you > both. Unless someone disagrees, I intend to update the proposal and > separate these 2 concepts in the next version of the document. > >> For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. >> A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. > > I completely agree. It would not make sense to support all features on > all platforms just for the sake of completeness. Each platform ought to > implement what is relevant in its case. > > That's what the current proposal tried to convey: a fully supported > platform must "build all configurations *supported by this platform*" > and "All *supported* configurations are tested in the CI". The key word > here is supported and that would be defined by the platform itself. But > I can see that maybe this wasn't clear enough. Your proposal below makes > that a lot clearer. > >> Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. > > Fair point. > > But is it something we should include in this proposal or should we push > it to a separate document setting expectations for the project's > documentation, which the current general proposal could refer to (as in, > "the platform should provide quality documentation up to the project's > criteria defined in document XXX')? > > This is definitely an important topic but I am wary of keeping the > tf.org proposal concise and focused at this point. I am worried that if > we put too much stuff in it discussions will diverge too much and we > might never reach an agreement. > > The same applies to testing standards for example, we could detail that > in the proposal or simply leave it to projects to define it separately. > >> Here is a more concrete proposal: >> >> Functional Support: >> Each project shall provide a standard feature or functionality list. >> Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. >> The platform documentation may reference a ticket if support is planned but not yet present. >> The platform documentation shall explicitly state if a feature or function has no plans for support. > > Regarding the last item, this would require all platform maintainers to > update their documentation every time a new feature is added to the > project's global list of features. This seems too much of a constraint > and unnecessary maintenance burden to me. > > I think a better, more lightweight alternative might be to let platform > maintainers list what's supported and if some feature is not listed, it > implies that it is not supported. This does not prevent platform > maintainers from indicating their future plans of supporting a feature > if they want to. > >> The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. >> In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. > > I can see that Joakim Bech proposed something similar, with more details > about how this was implemented for OP-TEE. > >> Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. > > Sorry I didn't get this, could you please elaborate? > >> Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. >> If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). > > If there's no appropriate tag in some cases, I guess we could always use > a git SHA1 of a specific commit. > >> Life Cycle State >> >> Fully Supported >> There is (at least) one active code owner for this platform. >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues are tracked >> Documentation is up to date >> >> Note: Projects should document standards on how "active" code ownership is measured and >> further document standards on how code owners are warned about impending life cycle state changes. > > Yes, good point, that is currently undefined in the proposal but I agree > that it needs defining per project. I will add an item in the last > section of the document. > > I am starting to think that we need a list of items to be defined per > project. This list would complement the general tf.org proposal. Things > like code owners/maintainers activity, code review timelines, and so on. > >> >> Orphan >> There is no active code owner >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) >> Documentation status is unclear since there is no active code owner. >> There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" > > I am confused, you said earlier that you would like to see the concepts > of support and functionality split out, but here you're listing 'orphan' > as one of the possible states... Did I miss your point? > >> Out of date >> Same as orphan, but either: >> there have been changes to the feature/functionality list, or >> there are failing tests without tracked tickets, or >> there are known documentation issues. >> >> Deprecated >> Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. >> >> Erik Shreve, PSEM >> Software Security Engineer & Architect (CMCU Platform Development)

5 years, 6 months

1
0
0 0

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

by Louis Mayencourt

Hi Raghu, I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and should lead to the same behavior. A mandatory property miss or a hit with a structurally incorrect node means that the DTB doesn't follow the provided binding document. Such a DTB shouldn't be considered as valid and should trigger a build failure and/or a code panic. With the current implementation, case 2 and 3 are similar. The property_getter() functions expect a specific format of the node. If a node is not found or structurally incorrect, the function will return an error code, which will lead to a panic(). regards, Louis ________________________________ 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: 06 April 2020 19:51 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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. > -- 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, 6 months

1
0
0 0

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

by Raghu Krishnamurthy

Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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, 6 months

1
0
0 0

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

by Louis Mayencourt

Hi Raghu, Let me try to clarify/reword my idea: We complete the fconf documentation with a binding document, which defines the nodes that should be present in the config DTB to consider it as valid/well-formed. The document contains two kinds of node: * mandatory (critical): the firmware can't proceed without this information (example: load address, image UUID, ...). If this node is not present in the DTS, the build fails and/or the code panic. * optional (no-critical): the firmware can assume or assign a default value and proceed (example: uart config, enable authentication flag, ...). Such a property is used to influence the default behavior of the firmware. >> This is non-deterministic failure. The miss of a mandatory (critical) node will always lead to a build failure / code panic. The miss of an optional (no-critical) node should not influence the default behavior of the firmware. >> Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the >> structure or number of nodes but allow the same integrator to miss a critical property in the DTB? A DTB with a missing mandatory (critical) property should not be considered well formed. >> If there is a missing critical property, is that not a badly formed DTB? With the above definition, it is. >> And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? With the rewording of "critical" / "no-critical" to "mandatory" / "optional", I think the situation is clearer: A DTB with a missing "optional" node/property is is still considered well-formed. I hope I answered your questions and clarify the idea behind the design. regards, Louis ________________________________ From: Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Sent: 05 April 2020 00:06 To: Louis Mayencourt <Louis.Mayencourt(a)arm.com> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. >>you can imagine a well-formed DTB which contain a >>critical set of properties and can contain some optional properties. This makes things even more confusing. The assumption we are asking code to make is that the DTB is always "well formed", ie don't check for structural issues such as extra nodes etc, but we are still making the distinctions between critical and non-critical properties, that may or may not exist in the DTB, which may or may not cause a panic. This is non-deterministic failure. Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the structure or number of nodes but allow the same integrator to miss a critical property in the DTB? If there is a missing critical property, is that not a badly formed DTB ? And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? -Raghu On 4/3/20 3:16 AM, Louis Mayencourt wrote: > Hi Raghu, > > I do agree that we need something similar to a binding document for > fconf properties. (similar to > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > At least for the common properties. > > The main idea behind the return code of the populator function was to > allow the code to handle no-critical property misses or to handle > critical failure by calling a platform hook. > With this in mind, you can imagine a well-formed DTB which contain a > critical set of properties and can contain some optional properties. The > return code and the populator "name" / "config" can be used to handle > this two cases. > > I tried to keep the design of fconf really simple, to leave room for > improvement according to feedbacks. Thanks for helping improving it! > > Regards, > Louis > ------------------------------------------------------------------------ > *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:* 03 April 2020 10:15 > *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] fconf: Validating config data > A further point is that the fconf populators return an error code and > panics on error today. But if we are making the assumption that the > DTB's are well formed, do we really need to fail or even return an error > code? > > -Raghu > > On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >> Hi All, (Sorry for the long email) >> >> The review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >> attempts to fix bounds check in the fconf populator code for the >> topology and SP's. During review, Sandrine thoughtfully pointed out that >> there were discussions around bounds check along the same lines in the >> review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >> it was deemed sufficient to have assertions in code and it was safe to >> make the assumption that the DTB is always well formed and contains >> valid values. I think this email mostly echoes Sandrine's concern from >> review 3492. >> >> While i agree with the assumptions, I am generally of the opinion that >> we should validate/range-check any data, even if it is signed. Being >> signed does not necessarily mean the data is well formed/valid. If there >> is a mistake in the build process and it is validly signed, it is >> possible that we silently corrupt state/data that could later be used to >> exploit firmware and/or make debugging hard. This is probably far >> fetched, but the cost of adding the check is trivial to avoid this >> possibility. >> >> I imagine the case where you have secure partitions signed by different >> entity other than the silicon provider(dual root-of-trust). A silicon >> provider provides a dev system for the SP provider to test and validate >> the SP's on silicon. The silicon has production firmware(and hence no >> assertions), but loads signed data from the SP provider which has some >> invalid values. There could be silent corruption without any indication >> whatsoever about what went wrong and it may be hard to debug if/when >> there are issues. >> Also, testing does not necessarily catch all invalid values since you >> will likely not get 100% coverage, given the number of config options >> available. Moreover, the code today, is not consistent in asserting on >> every property for valid values and the failure mode is not >> consistent/deterministic. It seems like every config option should have >> a list of valid values or a range of acceptable values that must be at a >> minimum asserted on. >> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >> is likely to be turned off since it really does not provide any >> security, so assuming we always have signed data might not be valid. >> >> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >> >> >> Thanks >> Raghu > -- > 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, 6 months

1
0
0 0

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

by Raghu Krishnamurthy

+tf-a list On 4/4/20 4:06 PM, Raghu Krishnamurthy wrote: > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. >> The return code and the populator "name" / "config" can be used to >> handle this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out >>> that there were discussions around bounds check along the same lines >>> in the review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe >>> to make the assumption that the DTB is always well formed and >>> contains valid values. I think this email mostly echoes Sandrine's >>> concern from review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion >>> that we should validate/range-check any data, even if it is signed. >>> Being signed does not necessarily mean the data is well formed/valid. >>> If there is a mistake in the build process and it is validly signed, >>> it is possible that we silently corrupt state/data that could later >>> be used to exploit firmware and/or make debugging hard. This is >>> probably far fetched, but the cost of adding the check is trivial to >>> avoid this possibility. >>> >>> I imagine the case where you have secure partitions signed by >>> different entity other than the silicon provider(dual root-of-trust). >>> A silicon provider provides a dev system for the SP provider to test >>> and validate the SP's on silicon. The silicon has production >>> firmware(and hence no assertions), but loads signed data from the SP >>> provider which has some invalid values. There could be silent >>> corruption without any indication whatsoever about what went wrong >>> and it may be hard to debug if/when there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting >>> on every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should >>> have a list of valid values or a range of acceptable values that must >>> be at a minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where >>> TRUSTED_BOARD_BOOT is likely to be turned off since it really does >>> not provide any security, so assuming we always have signed data >>> might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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, 7 months

1
0
0 0

Re: [TF-A] Change in ...trusted-firmware-a[integration]: Check for out-of-bound accesses in the CoT description

by Sandrine Bailleux

Hi Raghu, On 4/3/20 1:38 AM, Raghu Krishnamurthy via TF-A wrote: > Thanks Sandrine. Patches look good. Thanks for the review! > I realized after looking at things a little closer that i had > misunderstood how fconf works for io policies. I thought the image id's > themselves came from the config files and not just the UUID's, which is > why i was worried about bounds check, since the id was coming from an > external source(trusted or untrusted, depending on if it is signed data > or not). > This also made me realize that we are using another table built into > code, to convert from image id to UUID for io policies. Is there a > reason image id's also can't be discovered from the config file? I remember some internal discussions around this topic a few weeks ago. If I recall correctly, the current thinking is that down the line, we would like to move image IDs to DTBs but this looks complicated to achieve today because image IDs are used by several components in TF-A to tie things together. More work would be needed to abstract this properly everywhere. I think other folks in the team (Olivier? Manish? Louis?) might be able to comment further on this. Regards, Sandrine 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, 7 months

1
0
0 0

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

by Raghu Krishnamurthy

A further point is that the fconf populators return an error code and panics on error today. But if we are making the assumption that the DTB's are well formed, do we really need to fail or even return an error code? -Raghu On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: > Hi All, (Sorry for the long email) > > The review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 > attempts to fix bounds check in the fconf populator code for the > topology and SP's. During review, Sandrine thoughtfully pointed out that > there were discussions around bounds check along the same lines in the > review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and > it was deemed sufficient to have assertions in code and it was safe to > make the assumption that the DTB is always well formed and contains > valid values. I think this email mostly echoes Sandrine's concern from > review 3492. > > While i agree with the assumptions, I am generally of the opinion that > we should validate/range-check any data, even if it is signed. Being > signed does not necessarily mean the data is well formed/valid. If there > is a mistake in the build process and it is validly signed, it is > possible that we silently corrupt state/data that could later be used to > exploit firmware and/or make debugging hard. This is probably far > fetched, but the cost of adding the check is trivial to avoid this > possibility. > > I imagine the case where you have secure partitions signed by different > entity other than the silicon provider(dual root-of-trust). A silicon > provider provides a dev system for the SP provider to test and validate > the SP's on silicon. The silicon has production firmware(and hence no > assertions), but loads signed data from the SP provider which has some > invalid values. There could be silent corruption without any indication > whatsoever about what went wrong and it may be hard to debug if/when > there are issues. > Also, testing does not necessarily catch all invalid values since you > will likely not get 100% coverage, given the number of config options > available. Moreover, the code today, is not consistent in asserting on > every property for valid values and the failure mode is not > consistent/deterministic. It seems like every config option should have > a list of valid values or a range of acceptable values that must be at a > minimum asserted on. > I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT > is likely to be turned off since it really does not provide any > security, so assuming we always have signed data might not be valid. > > Anyway, is this decision worth revisiting? Too paranoid perhaps? :P > > > Thanks > Raghu

5 years, 7 months

1
0
0 0

fconf: Validating config data

by Raghu Krishnamurthy

Hi All, (Sorry for the long email) The review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 attempts to fix bounds check in the fconf populator code for the topology and SP's. During review, Sandrine thoughtfully pointed out that there were discussions around bounds check along the same lines in the review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and it was deemed sufficient to have assertions in code and it was safe to make the assumption that the DTB is always well formed and contains valid values. I think this email mostly echoes Sandrine's concern from review 3492. While i agree with the assumptions, I am generally of the opinion that we should validate/range-check any data, even if it is signed. Being signed does not necessarily mean the data is well formed/valid. If there is a mistake in the build process and it is validly signed, it is possible that we silently corrupt state/data that could later be used to exploit firmware and/or make debugging hard. This is probably far fetched, but the cost of adding the check is trivial to avoid this possibility. I imagine the case where you have secure partitions signed by different entity other than the silicon provider(dual root-of-trust). A silicon provider provides a dev system for the SP provider to test and validate the SP's on silicon. The silicon has production firmware(and hence no assertions), but loads signed data from the SP provider which has some invalid values. There could be silent corruption without any indication whatsoever about what went wrong and it may be hard to debug if/when there are issues. Also, testing does not necessarily catch all invalid values since you will likely not get 100% coverage, given the number of config options available. Moreover, the code today, is not consistent in asserting on every property for valid values and the failure mode is not consistent/deterministic. It seems like every config option should have a list of valid values or a range of acceptable values that must be at a minimum asserted on. I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT is likely to be turned off since it really does not provide any security, so assuming we always have signed data might not be valid. Anyway, is this decision worth revisiting? Too paranoid perhaps? :P Thanks Raghu

5 years, 7 months

1
0
0 0

Re: [TF-A] Change in ...trusted-firmware-a[integration]: Check for out-of-bound accesses in the CoT description

by Raghu Krishnamurthy

Thanks Sandrine. Patches look good. I realized after looking at things a little closer that i had misunderstood how fconf works for io policies. I thought the image id's themselves came from the config files and not just the UUID's, which is why i was worried about bounds check, since the id was coming from an external source(trusted or untrusted, depending on if it is signed data or not). This also made me realize that we are using another table built into code, to convert from image id to UUID for io policies. Is there a reason image id's also can't be discovered from the config file? -Raghu On 4/2/20 7:17 AM, Sandrine Bailleux (Code Review) wrote: > Hi guys, > > This is the patch I mentioned last Thursday at the TF-A tech call. Sorry > it took me so long to post it. > > View Change > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836> > > To view, visit change 3836 > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836>. > To unsubscribe, or for help writing mail filters, visit settings > <https://review.trustedfirmware.org/settings>. > > Gerrit-Project: TF-A/trusted-firmware-a > Gerrit-Branch: integration > Gerrit-Change-Id: Ic5ea20e43cf8ca959bb7f9b60de7c0839b390add > Gerrit-Change-Number: 3836 > Gerrit-PatchSet: 1 > Gerrit-Owner: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Reviewer: Louis Mayencourt <louis.mayencourt(a)arm.com> > Gerrit-Reviewer: Raghu K <raghu.ncstate(a)icloud.com> > Gerrit-Reviewer: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Comment-Date: Thu, 02 Apr 2020 14:17:12 +0000 > Gerrit-HasComments: No > Gerrit-Has-Labels: No > Gerrit-MessageType: comment

5 years, 7 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 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() ________________________________________________________________________________________________________ *** CID 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() 1707 other_name->value.hardware_module_name.oid.tag = MBEDTLS_ASN1_OID; 1708 other_name->value.hardware_module_name.oid.p = p; 1709 other_name->value.hardware_module_name.oid.len = len; 1710 1711 if( p + len >= end ) 1712 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1713 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1714 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1715 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1716 } 1717 p += len; 1718 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() 1685 { 1686 return( MBEDTLS_ERR_X509_FEATURE_UNAVAILABLE ); 1687 } 1688 1689 if( p + len >= end ) 1690 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1691 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1692 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1693 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1694 } 1695 p += len; 1696 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() 1722 other_name->value.hardware_module_name.val.tag = MBEDTLS_ASN1_OCTET_STRING; 1723 other_name->value.hardware_module_name.val.p = p; 1724 other_name->value.hardware_module_name.val.len = len; 1725 p += len; 1726 if( p != end ) 1727 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1728 mbedtls_platform_zeroize( other_name, 1729 sizeof( other_name ) ); 1730 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1731 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1732 } 1733 return( 0 ); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 7 months

1
0
0 0

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

by Sandrine Bailleux

Hi Joakim, On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: > Hi Christian, Sandrine, all, > > On Thu, Mar 26, 2020 at 10:27:14AM +0100, Sandrine Bailleux wrote: >> Hi Christian, >> >> Thanks a lot for the read and the comments! >> >> On 3/25/20 7:05 PM, Christian Daudt wrote: >>> ï¿½The maintenance proposal looks great ! I have some feedback on >>> specific portions: >>> ï¿½1. maintainer/owner/author patches. " Note that roles can be >>> cumulative, in particular the same individual can be both a code owner >>> and a maintainer. In such a scenario, the individual would be able to >>> self-merge a patch solely affecting his module, having the authority to >>> approve it from both a code owner and maintainer's point of view.": I'm >>> always leery of people self-approving their patches. At a minimum, all >>> self-patches should be published and a minimum wait time provided for >>> feedback. Or preferably that another maintainer does the merge (it does >>> not need to be mandated but should be suggested). >> >> Yes, actually this is something that generated some disagreement inside Arm >> as well and I am glad you're bringing this up here, as I'd like to hear more >> opinions on this. >> >> I too have concerns about allowing self-reviewing. I am not so much >> concerned about people potentially abusing of this situation to silently >> merge patches, as I think we should trust our maintainers. But I am worried >> that a self-review is rarely as good as a peer review, simply because it is >> so easy to miss things when it's your own work. I believe several pair of >> eyes is always better, as different people think differently, have different >> perspectives and backgrounds, and are able to catch different issues. >> >> But to pull this off, we need enough people to do all these reviews. The >> proposal currently allows self-review because some of us feared that >> mandating 2 reviewers for every patch (especially pure platform patches) >> would be impractical and too heavyweight, especially for the TF-M project in >> its current contributors organization, as I understand. It would be great to >> get more feedback from the TF-M community as to whether they think it could >> work in the end. >> >> It's a difficult balance between having the best possible code review >> practices, and realistically getting all the review work done in a timely >> manner, avoiding bottlenecks on specific people and keeping the flow of >> patches smooth. >> >> I like your idea of a minimum wait time provided for feedback. I think it >> could be a good middle ground solution. >> > +1 for that, after silence for X weeks it should be OK to merge the > patch. X would need to be number that is high enough for people to have > a chance to find it and look into it, but shouldn't be too high, since > there is a risk that it'll force the contributor to pile up things that > might be dependent on this patch. To throw something out, I'd say ~2 > weeks sounds like a good number to me. > >> Your other suggestion of having a different maintainer doing the merge would >> work as well IMO but requires more workforce. Again this comes down to >> whether this can realistically be achieved for each project. This solution >> was actually suggested within Arm as well (and even called out at the end of >> the proposal ;) ). >> >> Bottom line is, in an ideal world I would like to condemn self-review >> because I consider this as bad practice > +1 > >> , but I do not know whether this will >> be practical and will work for TF-M as well. >> >>> ï¿½2. 'timely manner': This expectation should be more explicit - when >>> the author can start requesting other maintainers to merge on assumption >>> that silence == approval (or not). Such timeliness expectations are >>> probably best set per project however. >> >> Yes, "timely manner" is definitely too vague and was actually left that way >> on purpose at this stage to avoid touching upon what I think is a sensitive >> subject! I am aware that some patches sometimes spend a long time in review, >> definitely longer than they should and it understandably generates some >> frustration. This is something we absolutely need to improve on IMO and >> hopefully a bigger pool of maintainers will help solve this issue. But I >> agree that the expected review timeline should be clearly established and it >> is probably best to let each project decides theirs. >> >>> ï¿½3. The proposal does not address branching strategies. i.e. will >>> there be separate maintainers for dev/master/stable branches? I don't >>> think it needs to address it yet - keep it simpler for a start. But a >>> todo saying something like "in the future this project maintenance >>> proposal might be expanded to address multi-branch maintainership" would >>> be good. >> >> Good point. A todo sounds good, I will add one in the last section of the >> document. >> >>> ï¿½4. The platform lifecycle state machine has too many transitions. >>> "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. >> >> Hmm OK. There might be too many transitions but I feel we need something >> between fully maintained and out, i.e. the limited support one. >> >> Julius Werner also pointed out on Thursday that orphan might be misplaced, >> as all these other stages deal with some degrees of feature support (what's >> known to work), whereas orphan is an orthogonal topic that is not directly >> related to the level of supported features. For example, a platform could >> have recently become orphan but all features and tests still work for some >> time. >> > At one point in time in the OP-TEE project we tried to keep track of > maintained platforms, by simply saying maintained "Yes" if they are > maintained. However they're not maintained, we indicated that by stating > the last known version where a platform was maintained. People can still > find that information here [1] (not up-to-date). The intention was to > give future users of an old platform a chance to know if it ever has > been supported and what version that was. That could serve as a starting > point in case someone is interested in bring a device/platform back to > life. Yes, I think such information can be very useful. It saves some "git archeology" effort to try and dig this information afterwards. Also, when someone starts looking at a project, I would expect this to be one of the first thing they look up, they would want to know in which shape the project is for the particular platform they are interested in. That's almost as important in my eyes as a "getting started" guide. We could have such a high-level table that just says whether a platform is supported or not (just a yes/no) and have complementary, per-platform documentation that goes into the details of what features are supported exactly. > How that works in practice is that all OP-TEE maintainers are adding > their "Tested-by" (see example [2]) tag for the platform they maintain > when we're doing a release. If there are platforms with no "Tested-by" > tag, then they simply end up with the "last known version". I think that's a very good idea! > However, to keep that up-to-date, it requires some discipline from the > people maintaining such a table ... something that we in the OP-TEE > project haven't been very good at :) Can't this be automated, such that it doesn't need to be manually kept up-to-date? I imagine we could have some tools generating the platform support table out of such a commit message. > So, I'm not proposing something, it's just that I wanted to share what > we've tried and it "works", but not easy to maintain (a release > checklist could fix that). > > [1] https://optee.readthedocs.io/en/latest/general/platforms.html > [2] https://github.com/OP-TEE/optee_os/pull/3309/commits/765b92604459240bed7fcf… >

5 years, 7 months

2
1
0 0

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

by Raghu Krishnamurthy

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

5 years, 7 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355291: Memory - corruptions (NEGATIVE_RETURNS) >>> Using variable "pos" as an index to array "hold_base". 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355290: Memory - corruptions (OVERRUN) >>> Overrunning array "hold_base" of 64 8-byte elements at element index 4294967295 (byte offset 34359738367) using index "pos" (which evaluates to 4294967295). 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 7 months

1
0
0 0

Patch-set review request: Adding Broadcom Platform support

by Sheetal Tigadoli

Hello TF-A, I understand most devs/reviewers will be busy working towards code freeze, but if its possible can this patch-set be reviewed. The patch-set is about "Add support for Broadcom platform". Patch-set link https://review.trustedfirmware.org/q/topic:%2522brcm_initial_support%2522 Thanks Sheetal

5 years, 7 months

1
0
0 0

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

by Shreve, Erik

Sandrine, Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. I'd like to see these split out. For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. Here is a more concrete proposal: Functional Support: Each project shall provide a standard feature or functionality list. Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. The platform documentation may reference a ticket if support is planned but not yet present. The platform documentation shall explicitly state if a feature or function has no plans for support. The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). Life Cycle State Fully Supported There is (at least) one active code owner for this platform. All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues are tracked Documentation is up to date Note: Projects should document standards on how "active" code ownership is measured and further document standards on how code owners are warned about impending life cycle state changes. Orphan There is no active code owner All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) Documentation status is unclear since there is no active code owner. There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" Out of date Same as orphan, but either: there have been changes to the feature/functionality list, or there are failing tests without tracked tickets, or there are known documentation issues. Deprecated Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Sandrine Bailleux via TF-M Sent: Tuesday, March 24, 2020 4:42 AM To: tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
2
0 0

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

by Sandrine Bailleux

Hi Andrej, On 3/26/20 10:54 AM, Andrej Butok via TF-A wrote: >> But I am worried that a self-review is rarely as good as a peer review > > On practice, unfortunately, some TF-M tasks are waiting weeks and even months for review and following approvals. > If I were a maintainer & owner of my own TFM area, I do not want to wait & push & remind somebody else. > Better to have a post-merge review for these cases, which does not limit and slow down the development. Thanks for the feedback. That's not good, patches can't realistically stay in review for weeks and even months, that's just not workable. Worse, it might discourage developers to contribute to the project. I can see that cumulating maintainer & owner roles would solve the problem here but perhaps enlarging the pool of maintainers would as well? Presumably, the situation is like that today because the current maintainers of the project are overloaded and cannot get all reviews done in a timely manner? I am skeptical about a post-merge review process... Once a patch is merged there is less urge and motivation (if any) for people to take a look at it. I am worried that patches might never get reviewed that way. Regards, Sandrine

5 years, 7 months

2
2
0 0

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

by Christian Daudt

Hi Sandrine, > Please find the initial proposal here: > > https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… > > Please provide any feedback you may have by replying to this email > thread, keeping all 4 mailing lists in the recipients list. > > I will collate comments from the community and try to incorporate them > in the document, keeping you updated on changes made between revisions. The maintenance proposal looks great ! I have some feedback on specific portions: 1. maintainer/owner/author patches. " Note that roles can be cumulative, in particular the same individual can be both a code owner and a maintainer. In such a scenario, the individual would be able to self-merge a patch solely affecting his module, having the authority to approve it from both a code owner and maintainer's point of view.": I'm always leery of people self-approving their patches. At a minimum, all self-patches should be published and a minimum wait time provided for feedback. Or preferably that another maintainer does the merge (it does not need to be mandated but should be suggested). 2. 'timely manner': This expectation should be more explicit - when the author can start requesting other maintainers to merge on assumption that silence == approval (or not). Such timeliness expectations are probably best set per project however. 3. The proposal does not address branching strategies. i.e. will there be separate maintainers for dev/master/stable branches? I don't think it needs to address it yet - keep it simpler for a start. But a todo saying something like "in the future this project maintenance proposal might be expanded to address multi-branch maintainership" would be good. 4. The platform lifecycle state machine has too many transitions. "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Thanks, Christian. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

3
2
0 0

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Varun Wadekar

Hello Pankaj, Hope you are doing well. The initial email point to one change, but I see that as the tip of a patch series. I reviewed https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 and left some comments, but did not review the complete patch series. Are you requesting a review of the entire patch series? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Tuesday, March 31, 2020 9:37 AM To: Pankaj Gupta <pankaj.gupta(a)nxp.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA External email: Use caution opening links or attachments Hi Pankaj, We will try, one of the arm team has done some +1 reviews and I have just kicked of a CI+2 run on the top of the patch stack. As you can imagine the Arm team is pressed for time the closer to the freeze date. Other TF-A contributors you all have +1 rights so if folks have time assistance with further +1 reviews would be appreciated as that would help in accelerating confidence is getting +2 and merging. Traditionally the project has relied on Arm folks but for some time now all contributors have had +1 rights on each other patches and the new project maintenance proposal is set up to take us in the direction of enabling all contributors helping each other. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Date: Monday, 30 March 2020 at 20:48 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj 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. -----------------------------------------------------------------------------------

5 years, 7 months

2
2
0 0

Re: [TF-A] RFR: Tegra fixes for v2.3

by Varun Wadekar

Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3819: include: context_mgmt: include ep_info.h * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3820: Tegra: enable EHF for watchdog timer interrupts * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3818: Tegra: remove ENABLE_SVE_FOR_NS = 0 Thanks. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Monday, March 30, 2020 10:02 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] RFR: Tegra fixes for v2.3 External email: Use caution opening links or attachments Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3731: Tegra: fixup GIC init from the 'on_finish' handler * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3770: Tegra186: increase memory mapped regions Thanks. ________________________________ 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, 7 months

1
0
0 0

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

by Varun Wadekar

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

5 years, 7 months

2
1
0 0

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Joanna Farley

Hi Pankaj, We will try, one of the arm team has done some +1 reviews and I have just kicked of a CI+2 run on the top of the patch stack. As you can imagine the Arm team is pressed for time the closer to the freeze date. Other TF-A contributors you all have +1 rights so if folks have time assistance with further +1 reviews would be appreciated as that would help in accelerating confidence is getting +2 and merging. Traditionally the project has relied on Arm folks but for some time now all contributors have had +1 rights on each other patches and the new project maintenance proposal is set up to take us in the direction of enabling all contributors helping each other. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Pankaj Gupta <pankaj.gupta(a)nxp.com> Date: Monday, 30 March 2020 at 20:48 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj 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, 7 months

1
0
0 0

Event Log for Measured Boot

by Alexei Fedorov

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.

5 years, 7 months

1
0
0 0

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Pankaj Gupta

Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj

5 years, 7 months

1
0
0 0

Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Pankaj Gupta

Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj

5 years, 7 months

1
0
0 0

RFR: Tegra fixes for v2.3

by Varun Wadekar

Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3731: Tegra: fixup GIC init from the 'on_finish' handler * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3770: Tegra186: increase memory mapped regions Thanks. ----------------------------------------------------------------------------------- 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, 7 months

1
0
0 0

GICv3 driver makefile

by Alexei Fedorov

Hello, As the prepartion for the series of patches for adding GICv3.1 and GICv4 support, please review and provide your comments for the patch which introduces GICv3 makefile and adds configuration options for the driver. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3754 Regards. 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.

5 years, 7 months

1
0
0 0

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

by Alexei Fedorov

Hi Raghu, Thanks for reviewing the proposal. Please find my answers below. 1) The idea was to use the same hash algorithm throughout all TF-A code for consistency and not introduce any new build flags. One of the initial implementations even didn't calculate the hash itself but was reading verified data provided by the Chain of Trust (CoT) for the purpose of optimisation. Existing definition of TF_MBEDTLS_HASH_ALG_ID in 'drivers\auth\mbedtls\mbedtls_common.mk' at line #76: ifeq (${HASH_ALG}, sha384) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA384 else ifeq (${HASH_ALG}, sha512) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA512 else TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA256 endif passed to 'include\drivers\auth\mbedtls\mbedtls_config.h', line #72 #define MBEDTLS_SHA256_C #if (TF_MBEDTLS_HASH_ALG_ID != TF_MBEDTLS_SHA256) #define MBEDTLS_SHA512_C #endif and used in Mbed TLS to define MBEDTLS_MD_MAX_SIZE in 'include\mbedtls\md.h': #if defined(MBEDTLS_SHA512_C) #define MBEDTLS_MD_MAX_SIZE 64 /* longest known is SHA512 */ #else #define MBEDTLS_MD_MAX_SIZE 32 /* longest known is SHA256 or less */ #endif makes impossible usage HASH_ALG=sha256 for TF-A and sha512 for Measured Boot calculations, because the following chain of function calls arm_bl1_set_bl2_hash() -> crypto_mod_calc_hash() -> crypto_lib_desc.calc_hash() -> calc_hash() -> mbedtls_md_info_from_type() returns CRYPTO_ERR_HASH error caused by insufficient space in internal Mbed TLS buffers and fixing this issue needs extra modifications in make and header files. Upgrading/changing the hash algorithm will require re-building of TF-A and re-flashing BL1 in ROM, so please explain what you mean by "potentially break measured boot on old devices in case a hash algorithm is broken" The functionality for getting the hash algorithm from the platform (e.g. eFuses) can be added later as a platform build option and requires fixing the issue described above. 2) Yes, Measured Boot requires TF-A built with TRUSTED_BOARD_BOOT option enabled, and as BL2 image is a part of CoT it is verified by BL1. 3) Yes. Event Log implementation is based on TCG Specifications. BL2 loads images, calculates their hashes and writes data into Event Log stored in Secure memory. 4) It is planned to add fTPM service implementation to TF-A, see Javier's message: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000339.html Stuart could also comment on the naming convention. 5) N/A 6) Event Log is a complex structure with entries of different lengths, and TFTF test checks the length of each field against the remaining size of the Event Log's data to be processed before accessing and printing the actual data. Thanks. 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: 21 March 2020 05:53 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Proposal for Measured Boot Implementation Hi Alexei, Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email. 1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ? Thanks -Raghu On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote: > Hello, > > I'm preparing the next set of patches for Measured Boot support in TF-A, > please find some details on design and implementation below. > > 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations > is passed as an existing build 'HASH_ALG' build parameter. > > 2. BL1 calculates BL2 image hash and passes these data to BL2 via > FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array > added > in 'fvp_fw_config.dts'. > > These changes are part of the patch under review, please see > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 > > 3. Event Log is calculated by BL2 in Secure Memory and copied to > Non-secure memory. Address in Non-secure memory is calculated as: > > "nt_fw_config_addr + nt_fw_config_max_size" > > with values obtained from 'tb_fw_config': > > nt_fw_config_addr = <0x0 0x80000000>; > nt_fw_config_max_size = <0x200>; > > 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG > device tree in 2 new added properties: > > Property name: 'tpm_event_log_addr' > Value type is an unsigned 64-bit integer specifying the physical address > of the Event Log. > > Property name: 'tpm_event_log_size' > Value type is an unsigned 32-bit integer specifying the size of the > Event Log. > > /* TPM Event Log Config */ > tpm_event_log { > compatible = "arm,nt_fw"; > tpm_event_log_addr = <0x0 0x0>; > tpm_event_log_size = <0x0>; > }; > > 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' > device tree, which address is passed by BL31 as 'arg0' parameter, > see TFTF patch: > > https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 > > 6. A new test which validates and prints Event Log data passed > in 'nt_fw_config' to BL33 will be added to TFTF. > > Please review and provide your comments on the proposed design. > > Regards. > 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. > -- 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, 7 months

3
7
0 0

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

by Andrej Butok

Hello, >But I am worried that a self-review is rarely as good as a peer review On practice, unfortunately, some TF-M tasks are waiting weeks and even months for review and following approvals. If I were a maintainer & owner of my own TFM area, I do not want to wait & push & remind somebody else. Better to have a post-merge review for these cases, which does not limit and slow down the development. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine Bailleux via TF-M Sent: Thursday, March 26, 2020 10:28 AM To: Christian Daudt <Christian.Daudt(a)cypress.com>; tf-a <tf-a(a)lists.trustedfirmware.org>; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: Re: [TF-M] Project Maintenance Proposal for tf.org Projects Hi Christian, Thanks a lot for the read and the comments! On 3/25/20 7:05 PM, Christian Daudt wrote: > ï¿½The maintenance proposal looks great ! I have some feedback on > specific portions: > ï¿½1. maintainer/owner/author patches. " Note that roles can be > cumulative, in particular the same individual can be both a code owner > and a maintainer. In such a scenario, the individual would be able to > self-merge a patch solely affecting his module, having the authority > to approve it from both a code owner and maintainer's point of view.": > I'm always leery of people self-approving their patches. At a minimum, > all self-patches should be published and a minimum wait time provided > for feedback. Or preferably that another maintainer does the merge (it > does not need to be mandated but should be suggested). Yes, actually this is something that generated some disagreement inside Arm as well and I am glad you're bringing this up here, as I'd like to hear more opinions on this. I too have concerns about allowing self-reviewing. I am not so much concerned about people potentially abusing of this situation to silently merge patches, as I think we should trust our maintainers. But I am worried that a self-review is rarely as good as a peer review, simply because it is so easy to miss things when it's your own work. I believe several pair of eyes is always better, as different people think differently, have different perspectives and backgrounds, and are able to catch different issues. But to pull this off, we need enough people to do all these reviews. The proposal currently allows self-review because some of us feared that mandating 2 reviewers for every patch (especially pure platform patches) would be impractical and too heavyweight, especially for the TF-M project in its current contributors organization, as I understand. It would be great to get more feedback from the TF-M community as to whether they think it could work in the end. It's a difficult balance between having the best possible code review practices, and realistically getting all the review work done in a timely manner, avoiding bottlenecks on specific people and keeping the flow of patches smooth. I like your idea of a minimum wait time provided for feedback. I think it could be a good middle ground solution. Your other suggestion of having a different maintainer doing the merge would work as well IMO but requires more workforce. Again this comes down to whether this can realistically be achieved for each project. This solution was actually suggested within Arm as well (and even called out at the end of the proposal ;) ). Bottom line is, in an ideal world I would like to condemn self-review because I consider this as bad practice, but I do not know whether this will be practical and will work for TF-M as well. > ï¿½2. 'timely manner': This expectation should be more explicit - > when the author can start requesting other maintainers to merge on > assumption that silence == approval (or not). Such timeliness > expectations are probably best set per project however. Yes, "timely manner" is definitely too vague and was actually left that way on purpose at this stage to avoid touching upon what I think is a sensitive subject! I am aware that some patches sometimes spend a long time in review, definitely longer than they should and it understandably generates some frustration. This is something we absolutely need to improve on IMO and hopefully a bigger pool of maintainers will help solve this issue. But I agree that the expected review timeline should be clearly established and it is probably best to let each project decides theirs. > ï¿½3. The proposal does not address branching strategies. i.e. will > there be separate maintainers for dev/master/stable branches? I don't > think it needs to address it yet - keep it simpler for a start. But a > todo saying something like "in the future this project maintenance > proposal might be expanded to address multi-branch maintainership" would be good. Good point. A todo sounds good, I will add one in the last section of the document. > ï¿½4. The platform lifecycle state machine has too many transitions. > "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Hmm OK. There might be too many transitions but I feel we need something between fully maintained and out, i.e. the limited support one. Julius Werner also pointed out on Thursday that orphan might be misplaced, as all these other stages deal with some degrees of feature support (what's known to work), whereas orphan is an orthogonal topic that is not directly related to the level of supported features. For example, a platform could have recently become orphan but all features and tests still work for some time. Regards, Sandrine -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 7 months

1
0
0 0

fTPM service implementation to test Measured Boot

by Javier Almansa Sobrino

Hello, Following up with the Proposal for Measured Boot Implementation described in https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000332.html , I am working on the implementation of a test fTPM service to exercise Measured Boot on TF-A. Some details about the implementation can be found below: 1.- The service will be based on Microsoft's reference implementation of the TPM 2.0 Specification by TCG. It will be implemented as an OP- TEE TA. 2.- During service initialisation, the fTPM service will read the TPM Event Log stored by Measured Boot in Secure Memory and it will extend it into the PCR specified by the log header. 3.- Alongside with the fTPM service, a test framework based on OP-TEE Toolkit is being implemented as well. This test framework will generate and run a Linux/Buildroot environment over a Foundation Model so the fTPM's PCRs can be accessed to verify its content. It is important here to highlight that this fTPM service and the related test framework are meant to be used only for demonstration purposes, it is not meant to be used as a production implementation. Please, let me know any comment or query you might have with regards this. Best regards, Javier

5 years, 7 months

1
0
0 0

Forthcoming Trusted Firmware-A 2.3 release

by Bipin Ravi

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.3 release during the third week of April as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.2 release. As part of this, a release candidate tag will be created and release activities will commence from Monday April 6th. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR's) desired to make the 2.2 release are submitted in good time to be complete by Friday April 3rd. Any major enhancement PR's still open after that date will not be merged until after the release. Thanks & best regards, [cid:image001.jpg@01D5F78C.8108B010] 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, 7 months

1
1
0 0

Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine

5 years, 7 months

1
0
0 0

Trusted Firmware Keynote @Linaro TechDays (Wed 25 Mar, 16:00-16:30 GMT)

by Matteo Carlini

Hi all, Trusted Firmware will be opening the Linaro Tech Days event on Wed 25th March at 4pm (16:00) GMT with a keynote presenting all the latest exciting news from the project. https://connect.linaro.org/resources/ltd20/ltd20-200k/ and, once registered, on sched: https://linarotechdays.sched.com/event/ZZFK/ltd20-200k-keynote-trusted-firm… The session will be live streamed and recorded (links in the above resources) and slides will be attached there too. Don't miss it! Thanks Matteo

5 years, 7 months

1
0
0 0

Re: [TF-A] Trusted Debug Control

by Matteo Carlini

Hi Victor, There's currently no plan to support Trusted Debug Control, primarily for the lack of an available platform IP component requiring it. Are you aware of a specific need for a real platform, that could also be available for testing the implementation? Thanks Matteo From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Victor Duan via TF-A Sent: 18 March 2020 01:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Debug Control Trusted Debug Control specified by TBBR CLIENT is as not supported in the current TF-A v2.2. Is there any plan to support it in the future? Thank you!

5 years, 7 months

1
0
0 0

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

by Raghu Krishnamurthy

Hi Alexei, Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email. 1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ? Thanks -Raghu On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote: > Hello, > > I'm preparing the next set of patches for Measured Boot support in TF-A, > please find some details on design and implementation below. > > 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations > is passed as an existing build 'HASH_ALG' build parameter. > > 2. BL1 calculates BL2 image hash and passes these data to BL2 via > FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array > added > in 'fvp_fw_config.dts'. > > These changes are part of the patch under review, please see > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 > > 3. Event Log is calculated by BL2 in Secure Memory and copied to > Non-secure memory. Address in Non-secure memory is calculated as: > > "nt_fw_config_addr + nt_fw_config_max_size" > > with values obtained from 'tb_fw_config': > > nt_fw_config_addr = <0x0 0x80000000>; > nt_fw_config_max_size = <0x200>; > > 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG > device tree in 2 new added properties: > > Property name: 'tpm_event_log_addr' > Value type is an unsigned 64-bit integer specifying the physical address > of the Event Log. > > Property name: 'tpm_event_log_size' > Value type is an unsigned 32-bit integer specifying the size of the > Event Log. > > /* TPM Event Log Config */ > tpm_event_log { > compatible = "arm,nt_fw"; > tpm_event_log_addr = <0x0 0x0>; > tpm_event_log_size = <0x0>; > }; > > 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' > device tree, which address is passed by BL31 as 'arg0' parameter, > see TFTF patch: > > https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 > > 6. A new test which validates and prints Event Log data passed > in 'nt_fw_config' to BL33 will be added to TFTF. > > Please review and provide your comments on the proposed design. > > Regards. > 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. >

5 years, 7 months

1
0
0 0

Re: [TF-A] Platforms to maintain their own Change Log files following 2.3 Release

by Varun Wadekar

>> As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Thanks for highlighting this. For Tegra platforms, we will provide up to date information to the platform change log after 2.3. We will have to live with the current state of the log for 2.3. >> Reviewers please continue to help determine if documentation is required for a given patch. Curious, have there been discussions around automating this somehow? E.g. add a tag to the commit message for a script to pick later. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Lauren Wehrmeister via TF-A Sent: Tuesday, March 17, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Platforms to maintain their own Change Log files following 2.3 Release External email: Use caution opening links or attachments Hi All, Following the TF-A release planned for April, platforms will be expected to maintain their own Change Log files to document relevant changes in platform specific code. The common TF-A Change Log will no longer document Platform specific updates after the 2.3 release. As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Reviewers please continue to help determine if documentation is required for a given patch. During each code freeze for a release the documentation in the upcoming change log will be moved to the change log corresponding to the release. Thanks, Lauren Wehrmeister ----------------------------------------------------------------------------------- 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, 7 months

2
2
0 0

Proposal for Measured Boot Implementation

by Alexei Fedorov

Hello, I'm preparing the next set of patches for Measured Boot support in TF-A, please find some details on design and implementation below. 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations is passed as an existing build 'HASH_ALG' build parameter. 2. BL1 calculates BL2 image hash and passes these data to BL2 via FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array added in 'fvp_fw_config.dts'. These changes are part of the patch under review, please see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 3. Event Log is calculated by BL2 in Secure Memory and copied to Non-secure memory. Address in Non-secure memory is calculated as: "nt_fw_config_addr + nt_fw_config_max_size" with values obtained from 'tb_fw_config': nt_fw_config_addr = <0x0 0x80000000>; nt_fw_config_max_size = <0x200>; 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG device tree in 2 new added properties: Property name: 'tpm_event_log_addr' Value type is an unsigned 64-bit integer specifying the physical address of the Event Log. Property name: 'tpm_event_log_size' Value type is an unsigned 32-bit integer specifying the size of the Event Log. /* TPM Event Log Config */ tpm_event_log { compatible = "arm,nt_fw"; tpm_event_log_addr = <0x0 0x0>; tpm_event_log_size = <0x0>; }; 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' device tree, which address is passed by BL31 as 'arg0' parameter, see TFTF patch: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 6. A new test which validates and prints Event Log data passed in 'nt_fw_config' to BL33 will be added to TFTF. Please review and provide your comments on the proposed design. Regards. 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.

5 years, 7 months

1
0
0 0

TF-A Tech Forum @ Thu 26 Mar 2020 17:00 - 18:00 (GMT)

by Joanna Farley

Hi All, The second TF-A Tech Forum is scheduled for next week for Thu 26 Mar 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. I have an agenda for next week however for future meetings if other project contributors would also like to present on topics please reach out to me and I will look to schedule. Agenda: * Technical Overview of the Fconf (Firmware Configuration) Feature by Louis Mayencourt * 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, 7 months

1
0
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 17:00 to 18:00 on Thursday (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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 17:00 to 18:00 on Thursday United Kingdom Time 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, 7 months

1
0
0 0

Trusted Debug Control

by Victor Duan

Trusted Debug Control specified by TBBR CLIENT is as not supported in the current TF-A v2.2. Is there any plan to support it in the future? Thank you!

5 years, 7 months

1
0
0 0

Platforms to maintain their own Change Log files following 2.3 Release

by Lauren Wehrmeister

Hi All, Following the TF-A release planned for April, platforms will be expected to maintain their own Change Log files to document relevant changes in platform specific code. The common TF-A Change Log will no longer document Platform specific updates after the 2.3 release. As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Reviewers please continue to help determine if documentation is required for a given patch. During each code freeze for a release the documentation in the upcoming change log will be moved to the change log corresponding to the release. Thanks, Lauren Wehrmeister

5 years, 7 months

1
0
0 0

RFR: Tegra changes for review pushed on 03/12/2020

by Varun Wadekar

Hello team, This is an email requesting reviews for the latest Tegra platform changes [1] from our downstream branch. Please review these changes at the earliest and help us get them merged before the release candidate tag is generated. We hope to push one more batch for v2.3, after [1] gets merged. Thanks in advance. Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-03122020%22+… ----------------------------------------------------------------------------------- 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, 7 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 354931: Parse warnings (PARSE_ERROR) /lib/xlat_tables_v2/xlat_tables_context.c: 34 in () ________________________________________________________________________________________________________ *** CID 354931: Parse warnings (PARSE_ERROR) /lib/xlat_tables_v2/xlat_tables_context.c: 34 in () 28 #if PLAT_RO_XLAT_TABLES 29 #define BASE_XLAT_TABLE_SECTION ".rodata" 30 #else 31 #define BASE_XLAT_TABLE_SECTION ".bss" 32 #endif 33 >>> CID 354931: Parse warnings (PARSE_ERROR) >>> expected a string literal 34 REGISTER_XLAT_CONTEXT(tf, MAX_MMAP_REGIONS, MAX_XLAT_TABLES, 35 PLAT_VIRT_ADDR_SPACE_SIZE, PLAT_PHY_ADDR_SPACE_SIZE, 36 BASE_XLAT_TABLE_SECTION); 37 38 void mmap_add_region(unsigned long long base_pa, uintptr_t base_va, size_t size, 39 unsigned int attr) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads: address implementation concerns

by Sandrine Bailleux

Hi Sumit, On 3/4/20 4:55 PM, Sumit Garg via TF-A wrote: >> The last remaining item would be to address the MISRA violations >> that Coverity found, which I've copied & pasted for you on Gerrit in the >> top patch. > > I have tried to address most of MISRA violations and updated the > patch-set. But since I don't have access to Coverity tool you are > using, so can you please check if there is any relevant MISRA > violation that I missed? Sure, I will re-run the tool in our internal CI and let you know the results. >> Also, this feature is only used on QEMU right now and I am not aware of >> anyone trying to enable it for their platforms just yet. Thus there is a >> risk we might have overlooked some issues that we'll discover at that time. > > Socionext being a silicon vendor is actively looking for this feature > and I think they will build upon this feature to enable firmware > encryption on their platforms to meet DRM robustness rules. Interesting, thanks for sharing this information. >> Furthermore, I know that you've done some testing of this feature on >> QEMU but this is not integrated into the CI loop right now. Thus, there >> is a risk that we might break it in the future and this will go >> unnoticed, unless you plan to test it regularly on your end. > > Yeah we should plan to enable testing for this feature in CI loop. For now, I've added in our internal CI a simple build test based on the build instructions you've provided in the patch set. This will at least make sure we do not break the build inadvertently in the future. But as you say, going forward, we should plan for proper testing on QEMU. I am hoping we will soon be able to extend the OpenCI [1] and add this support there. [1] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000264.html >> * Saying so in the (upcoming) change log. > > I hope you can take care of this. Actually this is something you have access to, it's a matter of adding a line in docs/change-log-upcoming.rst in the TF-A source tree. Regards, Sandrine

5 years, 7 months

2
1
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads: address implementation concerns

by Sumit Garg

Hi Everyone, I have tried to address most of the implementation concerns with updated patch-set [1] as follows: *Concern*: Firmware encryption bit needs to be signed *Address*: Moved the firmware encryption bit from FIP ToC header to "io_uuid_spec_t" struct which is part of "plat_io_policy" that is embedded in the boot-loader (BL1 or BL2) and hence firmware encryption bit is signed. Also, with this implementation fip_tool is no longer aware of encryption and just encrypted binaries are piped to fip_tool. *Concern*: Capability to encrypt with different keys for different images *Address*: Passed "img_id" buffer reference as an argument of "plat_get_enc_key_info()" API. So that platforms may choose to either provide a unique key per firmware image or just derive a key from HUK per firmware using "img_id" buffer as a salt. *Concern*: Coupling of FIP and encryption layer *Address*: Firstly I think we all can agree that encryption layer provides confidentiality protection specific to IO storage. Secondly FIP is actually a packaging layer that sits over actual IO layer and having the encryption layer coupled with FIP provides an abstraction layer for any FIP payload which in turn provides the following features: 1. Allows the firmware certificates to be encrypted as well to protect against cloning satisfying R050_TBBR_PROTECTION requirement. 2. Allows the firmware configuration data to be encrypted as well. 3. Provides a capability to have a secure key store as FIP payload which is protected using HUK. *Concern*: Allow usage of alternative verify-then-decrypt method *Address*: A platform could disable this encryption layer and implement decryption as part of "bl2_plat_handle_post_image_load()". Please let me know in case I missed any implementation concerns and feel free to provide your feedback on updated patch-set [1]. [1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op… Regards, Sumit

5 years, 8 months

4
11
0 0

Re: [TF-A] Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1

by Petre-Ionut Tudor

Hi Masahiro, That warning is expected. GCC complains about this, since tf_base_xlat_table is not constant and we are asking it to be put in a read-only section (see the REGISTER_XLAT_CONTEXT_RO_BASE_TABLE macro). This is fine since: * We only want the base table to be read-only after the tables have been initialized. The only time we change tf_base_xlat_table is when we initialize it, and at that point in the platform setup sequence the MMU is off, so permissions have no effect. * We never write to this with the MMU on (it's the level 1 translation table), so there is no danger of generating MMU faults. I hope this answers your question. Thanks Petre ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Masahiro Yamada via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 March 2020 12:30 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1 Hi. If I build TF-A with ALLOW_RO_XLAT_TABLES=1, the base xlat table goes into .rodata section instead of .bss section. Then, I see a warning like: /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata Is this a know issue? [Reproduce Command] make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 The full build log is below: masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 CC lib/libfdt/fdt.c CC lib/libfdt/fdt_addresses.c CC lib/libfdt/fdt_empty_tree.c CC lib/libfdt/fdt_ro.c CC lib/libfdt/fdt_rw.c CC lib/libfdt/fdt_strerror.c CC lib/libfdt/fdt_sw.c CC lib/libfdt/fdt_wip.c AR build/fvp/release/lib/libfdt.a Building fvp CC lib/libc/abort.c CC lib/libc/assert.c CC lib/libc/exit.c CC lib/libc/memchr.c CC lib/libc/memcmp.c CC lib/libc/memcpy.c CC lib/libc/memmove.c CC lib/libc/memrchr.c CC lib/libc/memset.c CC lib/libc/printf.c CC lib/libc/putchar.c CC lib/libc/puts.c CC lib/libc/snprintf.c CC lib/libc/strchr.c CC lib/libc/strcmp.c CC lib/libc/strlcpy.c CC lib/libc/strlen.c CC lib/libc/strncmp.c CC lib/libc/strnlen.c CC lib/libc/strrchr.c AS lib/libc/aarch64/setjmp.S AR build/fvp/release/lib/libc.a CC drivers/arm/smmu/smmu_v3.c CC drivers/arm/sp805/sp805.c CC drivers/delay_timer/delay_timer.c CC drivers/io/io_semihosting.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl1_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC drivers/arm/cci/cci.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl1_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC bl1/bl1_main.c CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC lib/cpus/errata_report.c CC lib/el3_runtime/aarch64/context_mgmt.c CC plat/common/plat_bl1_common.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS bl1/aarch64/bl1_entrypoint.S AS bl1/aarch64/bl1_exceptions.S AS lib/cpus/aarch64/cpu_helpers.S AS plat/common/aarch64/platform_up_stack.S AS lib/cpus/aarch64/dsu_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl1/bl1.ld.S LD build/fvp/release/bl1/bl1.elf BIN build/fvp/release/bl1.bin Built build/fvp/release/bl1.bin successfully OD build/fvp/release/bl1/bl1.dump CC drivers/arm/sp805/sp805.c CC drivers/io/io_semihosting.c CC lib/utils/mem_region.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl2_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl2_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c CC plat/arm/common/arm_image_load.c CC common/desc_image_load.c CC bl2/bl2_image_load_v2.c CC bl2/bl2_main.c CC bl2/aarch64/bl2_arch_setup.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS lib/locks/exclusive/aarch64/spinlock.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS bl2/aarch64/bl2_entrypoint.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2/bl2.ld.S LD build/fvp/release/bl2/bl2.elf BIN build/fvp/release/bl2.bin Built build/fvp/release/bl2.bin successfully OD build/fvp/release/bl2/bl2.dump CC drivers/arm/fvp/fvp_pwrc.c CC drivers/arm/smmu/smmu_v3.c CC drivers/delay_timer/delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC lib/utils/mem_region.c CC plat/arm/board/fvp/fvp_bl31_setup.c CC plat/arm/board/fvp/fvp_pm.c CC plat/arm/board/fvp/fvp_topology.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/gic/common/gic_common.c CC drivers/arm/gic/v3/gicv3_main.c CC drivers/arm/gic/v3/gicv3_helpers.c CC plat/common/plat_gicv3.c CC plat/arm/common/arm_gicv3.c CC drivers/arm/gic/v3/gic500.c CC drivers/arm/cci/cci.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/generic_delay_timer.c CC lib/cpus/aarch64/cpuamu.c CC plat/arm/common/arm_bl31_setup.c CC plat/arm/common/arm_pm.c CC plat/arm/common/arm_topology.c CC plat/common/plat_psci_common.c CC plat/arm/common/aarch64/execution_state_switch.c CC plat/arm/common/arm_sip_svc.c CC lib/pmf/pmf_smc.c CC bl31/bl31_main.c CC bl31/interrupt_mgmt.c CC bl31/bl31_context_mgmt.c CC common/runtime_svc.c CC services/arm_arch_svc/arm_arch_svc_setup.c CC services/std_svc/std_svc_setup.c CC lib/el3_runtime/cpu_data_array.c CC lib/el3_runtime/aarch64/context_mgmt.c CC lib/cpus/errata_report.c CC lib/psci/psci_off.c CC lib/psci/psci_on.c CC lib/psci/psci_suspend.c CC lib/psci/psci_common.c CC lib/psci/psci_main.c CC lib/psci/psci_setup.c CC lib/psci/psci_system_off.c CC lib/psci/psci_mem_protect.c CC lib/locks/bakery/bakery_lock_coherent.c CC lib/psci/psci_stat.c CC lib/pmf/pmf_main.c CC lib/extensions/spe/spe.c CC lib/extensions/amu/aarch64/amu.c CC lib/extensions/sve/sve.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS lib/cpus/aarch64/cpuamu_helpers.S AS bl31/aarch64/bl31_entrypoint.S AS bl31/aarch64/crash_reporting.S AS bl31/aarch64/ea_delegate.S AS bl31/aarch64/runtime_exceptions.S AS lib/cpus/aarch64/dsu_helpers.S AS plat/common/aarch64/platform_mp_stack.S AS lib/el3_runtime/aarch64/cpu_data.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/locks/exclusive/aarch64/spinlock.S AS lib/psci/aarch64/psci_helpers.S AS lib/el3_runtime/aarch64/context.S AS lib/extensions/amu/aarch64/amu_helpers.S AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl31/bl31.ld.S LD build/fvp/release/bl31/bl31.elf BIN build/fvp/release/bl31.bin Built build/fvp/release/bl31.bin successfully OD build/fvp/release/bl31/bl31.dump CC plat/arm/board/fvp/fvp_bl2u_setup.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC plat/arm/common/arm_bl2u_setup.c CC bl2u/bl2u_main.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS bl2u/aarch64/bl2u_entrypoint.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2u/bl2u.ld.S LD build/fvp/release/bl2u/bl2u.elf BIN build/fvp/release/bl2u.bin Built build/fvp/release/bl2u.bin successfully OD build/fvp/release/bl2u/bl2u.dump CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts CPP fdts/fvp-base-gicv3-psci.dts DTC fdts/fvp-base-gicv3-psci.dts ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5: Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000: simple-bus unit address format error, expected "0" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5: Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000: simple-bus unit address format error, expected "200000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5: Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000: simple-bus unit address format error, expected "202000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5: Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5: Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000: simple-bus unit address format error, expected "300000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5: Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or empty reg/ranges property -- Best Regards Masahiro Yamada -- 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, 8 months

1
0
0 0

Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1

by Masahiro Yamada

Hi. If I build TF-A with ALLOW_RO_XLAT_TABLES=1, the base xlat table goes into .rodata section instead of .bss section. Then, I see a warning like: /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata Is this a know issue? [Reproduce Command] make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 The full build log is below: masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 CC lib/libfdt/fdt.c CC lib/libfdt/fdt_addresses.c CC lib/libfdt/fdt_empty_tree.c CC lib/libfdt/fdt_ro.c CC lib/libfdt/fdt_rw.c CC lib/libfdt/fdt_strerror.c CC lib/libfdt/fdt_sw.c CC lib/libfdt/fdt_wip.c AR build/fvp/release/lib/libfdt.a Building fvp CC lib/libc/abort.c CC lib/libc/assert.c CC lib/libc/exit.c CC lib/libc/memchr.c CC lib/libc/memcmp.c CC lib/libc/memcpy.c CC lib/libc/memmove.c CC lib/libc/memrchr.c CC lib/libc/memset.c CC lib/libc/printf.c CC lib/libc/putchar.c CC lib/libc/puts.c CC lib/libc/snprintf.c CC lib/libc/strchr.c CC lib/libc/strcmp.c CC lib/libc/strlcpy.c CC lib/libc/strlen.c CC lib/libc/strncmp.c CC lib/libc/strnlen.c CC lib/libc/strrchr.c AS lib/libc/aarch64/setjmp.S AR build/fvp/release/lib/libc.a CC drivers/arm/smmu/smmu_v3.c CC drivers/arm/sp805/sp805.c CC drivers/delay_timer/delay_timer.c CC drivers/io/io_semihosting.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl1_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC drivers/arm/cci/cci.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl1_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC bl1/bl1_main.c CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC lib/cpus/errata_report.c CC lib/el3_runtime/aarch64/context_mgmt.c CC plat/common/plat_bl1_common.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS bl1/aarch64/bl1_entrypoint.S AS bl1/aarch64/bl1_exceptions.S AS lib/cpus/aarch64/cpu_helpers.S AS plat/common/aarch64/platform_up_stack.S AS lib/cpus/aarch64/dsu_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl1/bl1.ld.S LD build/fvp/release/bl1/bl1.elf BIN build/fvp/release/bl1.bin Built build/fvp/release/bl1.bin successfully OD build/fvp/release/bl1/bl1.dump CC drivers/arm/sp805/sp805.c CC drivers/io/io_semihosting.c CC lib/utils/mem_region.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl2_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl2_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c CC plat/arm/common/arm_image_load.c CC common/desc_image_load.c CC bl2/bl2_image_load_v2.c CC bl2/bl2_main.c CC bl2/aarch64/bl2_arch_setup.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS lib/locks/exclusive/aarch64/spinlock.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS bl2/aarch64/bl2_entrypoint.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2/bl2.ld.S LD build/fvp/release/bl2/bl2.elf BIN build/fvp/release/bl2.bin Built build/fvp/release/bl2.bin successfully OD build/fvp/release/bl2/bl2.dump CC drivers/arm/fvp/fvp_pwrc.c CC drivers/arm/smmu/smmu_v3.c CC drivers/delay_timer/delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC lib/utils/mem_region.c CC plat/arm/board/fvp/fvp_bl31_setup.c CC plat/arm/board/fvp/fvp_pm.c CC plat/arm/board/fvp/fvp_topology.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/gic/common/gic_common.c CC drivers/arm/gic/v3/gicv3_main.c CC drivers/arm/gic/v3/gicv3_helpers.c CC plat/common/plat_gicv3.c CC plat/arm/common/arm_gicv3.c CC drivers/arm/gic/v3/gic500.c CC drivers/arm/cci/cci.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/generic_delay_timer.c CC lib/cpus/aarch64/cpuamu.c CC plat/arm/common/arm_bl31_setup.c CC plat/arm/common/arm_pm.c CC plat/arm/common/arm_topology.c CC plat/common/plat_psci_common.c CC plat/arm/common/aarch64/execution_state_switch.c CC plat/arm/common/arm_sip_svc.c CC lib/pmf/pmf_smc.c CC bl31/bl31_main.c CC bl31/interrupt_mgmt.c CC bl31/bl31_context_mgmt.c CC common/runtime_svc.c CC services/arm_arch_svc/arm_arch_svc_setup.c CC services/std_svc/std_svc_setup.c CC lib/el3_runtime/cpu_data_array.c CC lib/el3_runtime/aarch64/context_mgmt.c CC lib/cpus/errata_report.c CC lib/psci/psci_off.c CC lib/psci/psci_on.c CC lib/psci/psci_suspend.c CC lib/psci/psci_common.c CC lib/psci/psci_main.c CC lib/psci/psci_setup.c CC lib/psci/psci_system_off.c CC lib/psci/psci_mem_protect.c CC lib/locks/bakery/bakery_lock_coherent.c CC lib/psci/psci_stat.c CC lib/pmf/pmf_main.c CC lib/extensions/spe/spe.c CC lib/extensions/amu/aarch64/amu.c CC lib/extensions/sve/sve.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS lib/cpus/aarch64/cpuamu_helpers.S AS bl31/aarch64/bl31_entrypoint.S AS bl31/aarch64/crash_reporting.S AS bl31/aarch64/ea_delegate.S AS bl31/aarch64/runtime_exceptions.S AS lib/cpus/aarch64/dsu_helpers.S AS plat/common/aarch64/platform_mp_stack.S AS lib/el3_runtime/aarch64/cpu_data.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/locks/exclusive/aarch64/spinlock.S AS lib/psci/aarch64/psci_helpers.S AS lib/el3_runtime/aarch64/context.S AS lib/extensions/amu/aarch64/amu_helpers.S AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl31/bl31.ld.S LD build/fvp/release/bl31/bl31.elf BIN build/fvp/release/bl31.bin Built build/fvp/release/bl31.bin successfully OD build/fvp/release/bl31/bl31.dump CC plat/arm/board/fvp/fvp_bl2u_setup.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC plat/arm/common/arm_bl2u_setup.c CC bl2u/bl2u_main.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS bl2u/aarch64/bl2u_entrypoint.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2u/bl2u.ld.S LD build/fvp/release/bl2u/bl2u.elf BIN build/fvp/release/bl2u.bin Built build/fvp/release/bl2u.bin successfully OD build/fvp/release/bl2u/bl2u.dump CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts CPP fdts/fvp-base-gicv3-psci.dts DTC fdts/fvp-base-gicv3-psci.dts ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5: Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000: simple-bus unit address format error, expected "0" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5: Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000: simple-bus unit address format error, expected "200000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5: Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000: simple-bus unit address format error, expected "202000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5: Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5: Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000: simple-bus unit address format error, expected "300000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5: Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or empty reg/ranges property -- Best Regards Masahiro Yamada

5 years, 8 months

1
0
0 0

Re: [TF-A] Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Hi All, I’ll be running the TF-A Tech Forum next week and I wanted to give an idea of what to expect in this inaugural meeting. While in future meetings I will want to seek input of what the agenda will be before the meeting with the option for other project contributors to present on topics in this first one I have a set agenda which is influenced by the format used in the counterpart TF-M Tech Forum. Agenda: * Introduction to the TF-A Technical Forum Meeting * Technical Overview of the Debug-FS Feature * Optional TF-A Mailing List Topic Discussions Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Bill Fletcher via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Bill Fletcher <bill.fletcher(a)linaro.org> Date: Friday, 28 February 2020 at 15:25 To: <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a(a)lists.trustedfirmware.org) This event has been changed. TF-A Tech Forum When Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who (Guest list has been hidden at organiser's request) more details »<https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY…> Changed: We are starting 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. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> (updated due to content filtering issues) Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. -- 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, 8 months

1
0
0 0

GICv3 driver changes

by Alexei Fedorov

Hello, I'm preparing a set of patches for GICv3 driver for GICv3.1 and GICv4 support. Please review and provide your comments for the 1st patch which separates GICD and GICR accessor functions and adds new macros for GICv3 registers access. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3550 Regards. 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.

5 years, 8 months

1
0
0 0

debug

by Iñigo Vicente Waliño

Hi, Is there any way to see through the console or to debug the TFA on the imx8m board? Best

5 years, 8 months

1
0
0 0

Imx8m mini boot

by Iñigo Vicente Waliño

Hi, Is there any way to see the traceability or registers by the command line of the secure boot on my imx8m mini board with u-boot? Thanks Iñigo

5 years, 8 months

1
0
0 0

Review request

by Pramod Kumar

Hi All, Please help me reviewing below patches- https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3580 Regards, Pramod

5 years, 8 months

1
0
0 0

Tentatively Accepted: TF-A Tech Forum @ Thu Mar 12, 2020 10:30pm - 11:30pm (IST) (Bill Fletcher via TF-A)

by sandeep.tripathy＠broadcom.com

sandeep.tripathy(a)broadcom.com has replied "Maybe" to this invitation. Title: TF-A Tech Forum This meeting originally contained an attachment. Please contact your organizer for the attachment. This event has been changed. TF-A Tech Forum When Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who (Guest list has been hidden at organiser's request) more details » Changed: We are starting 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. Future invites will be 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/ Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974 Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h (updated due to content filtering issues) Going (tf-a(a)lists.trustedfirmware.org)? Yes - Maybe - No more options » Invitation from Google 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 . When: Thu Mar 12, 2020 10:30pm – 11:30pm India Standard Time - Kolkata Calendar: Bill Fletcher via TF-A Who: * Bill Fletcher via TF-A - organizer * sandeep.tripathy(a)broadcom.com - creator 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 organizer and be added to the guest list, or 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, 8 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed. Title: TF-A Tech Forum We are starting 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. Future invites will be 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  (updated due to content filtering issues) (changed) When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time 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=MGVhNDdsMGVqNnEzZ3BpY… 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, 8 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We are starting 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. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time 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=MGVhNDdsMGVqNnEzZ3BpY… 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, 8 months

1
0
0 0

Re: [TF-A] FIP header flags available for feature selection

by Soby Mathew

Hi Scott Please add the platform specific flags as a field in fip_dev_state_t. typedef struct { uintptr_t dev_spec; uint32_t plat_toc_flag; } fip_dev_state_t; Then this field can be updated as part of verifying the FIP header. This header needs to be cleared when the device is closed. Introduce a helper in fip driver to query the flags: int fip_dev_get_plat_toc_flag(io_dev_info_t *dev_info, uint32_t *plat_toc_flag); That should satisfy your requirement. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Scott > Branden via TF-A > Sent: 07 February 2020 18:57 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] FIP header flags available for feature selection > > Hello, > > The fip header has reserved fields available for platform specific use. > The fiptool allows these header fields to be filled in using the --plat-toc-flags. > > A call needs to be available in the ATF framework to get these flags without > accessing the FIP file again to get these flags. > We have a solution we've used for ATF for quite some time to access these > flags. > > It's finally being upstreamed here: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 > > If there are any other efficient methods to access these flags or a better > proposal please suggest. > > Thanks, > Scott > -- > 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, 8 months

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Sandrine Bailleux

Hi Raghu, Thanks a lot for the review comments and feedback! On 2/25/20 3:45 AM, Raghu Krishnamurthy via TF-A wrote: > The patch stack looks great! I do have a suggestion for the long term > evolution/future work on root's of trust and cert_create. It would be > great to generalize "dual-root" to "multi-root". It is conceivable that > firmware supporting secure partitions/SPCI etc, could move to having > multiple root's of trust. Here we have the silicon provider, and the > platform owner as two roots, but a more complex system could contain > silicon firmware, platform firmware and multiple secure partitions, each > signed by different entities. To remove the signing dependencies between > each of these entities, we could have a ROTPK for each of these entities > and the same solution used here, can be applied to solve multiple root's > of trust and is summarized very well by your statement -"As long as > there is a defined contract between BL2 and the (P)(*)ROTK-rooted images > as to how/where to securely get this key or hash, there should not be > any need for the two vendors to do any cross-signing." >> To do this, If possible, we should start moving away from tables such as > the ones in cert_create/src/dualroot/cot.c and have platforms provide > the certificate dependencies and keys used to sign them in a config > file. This achieves two things: it makes cert_create independent of the > cert chain a platform wants to use and the number of roots of trust, > and, makes cert_create more usable by reducing the number of command > line arguments to be provided, which is a long list today. You could > potentially use the config file provided to auto generate the tbbr_cot.c > file being linked into the firmware too. > > Let me know what you think. I agree with everything you said above. Indeed, there's no reason to stop at 2 roots of trust and as you pointed out there are real use cases to enable more. The dualroot chain of trust is only the first step in that direction and is a useful way to experiment with extending the TBBR implementation and chain of trust, while addressing a real use case. Also completely agree with the lack of flexibility of the hard-coded chain of trust in cert_create/src/dualroot/cot.c and drivers/auth/dualroot/cot.c for that matter. In fact, we (at Arm) are thinking along the same lines as you and have had similar ideas boiling for some time. We are making gradual changes to introduce more flexibility into TF-A, not just for the chain of trust, but for any platform-specific data. Maybe you've seen the recent FConf framework patches, which is a key piece into enabling platform layers to move platform-specific data into configuration files. There is still work to do but down the line we are already thinking about moving the chain of trust description into such a configuration file. Moving the CoT into a configuration file has many advantages: - It could constitute the single input source for the chain of trust, serving both the cert_create tool and the firmware. Today, the CoT is described and duplicated in both places and there is really no good reason to keep things like that IMO. As you said, we could auto-generate the tbbr_cot.c file and build into the firmware, or even have the firmware dynamically parse the configuration file at runtime and extract its CoT. - It could simplify the description of the CoT. Today, I think that the C data structures in tbbr_cot.c are quite complex and not straight-forward to understand at first. If we described them using some configuration language, I believe we could abstract some of these details away or at least organize them in a more intuitive way. Regards, Sandrine

5 years, 8 months

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Raghu Krishnamurthy

Hi Sandrine, The patch stack looks great! I do have a suggestion for the long term evolution/future work on root's of trust and cert_create. It would be great to generalize "dual-root" to "multi-root". It is conceivable that firmware supporting secure partitions/SPCI etc, could move to having multiple root's of trust. Here we have the silicon provider, and the platform owner as two roots, but a more complex system could contain silicon firmware, platform firmware and multiple secure partitions, each signed by different entities. To remove the signing dependencies between each of these entities, we could have a ROTPK for each of these entities and the same solution used here, can be applied to solve multiple root's of trust and is summarized very well by your statement -"As long as there is a defined contract between BL2 and the (P)(*)ROTK-rooted images as to how/where to securely get this key or hash, there should not be any need for the two vendors to do any cross-signing." To do this, If possible, we should start moving away from tables such as the ones in cert_create/src/dualroot/cot.c and have platforms provide the certificate dependencies and keys used to sign them in a config file. This achieves two things: it makes cert_create independent of the cert chain a platform wants to use and the number of roots of trust, and, makes cert_create more usable by reducing the number of command line arguments to be provided, which is a long list today. You could potentially use the config file provided to auto generate the tbbr_cot.c file being linked into the firmware too. Let me know what you think. Thanks Raghu On 2/24/20 3:43 AM, Sandrine Bailleux via TF-A wrote: > Hi, > > Following up on my email sent in November 2019: > https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html > > and the proof-of-concept code and documentation shared at that time: > [1] > https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 > > I've made a number of improvements and cleanups in the code. I am > posting a new version that introduces this new chain of trust (called > "dualroot", as it has 2 roots of trust) as an alternative to the default > TBBR one. Right now, it is only enabled on some Arm platforms but it > should be pretty straight-forward to extend this to other platforms. > > The code is available there: > https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22 > > and is comprised of the following patches: > - Introduce a new "dualroot" chain of trust > - cert_create: Define the dualroot CoT > - Build system: Changes to drive cert_create for dualroot CoT > - plat/arm: Provide some PROTK files for development > - plat/arm: Add support for dualroot CoT > - plat/arm: Pass cookie argument down to arm_get_rotpk_info() > - plat/arm: Retrieve the right ROTPK when using the dualroot CoT > > This patch stack is based on preparatory work (which has already been > merged) to select a different CoT. This patch stack: > - Did some build system refactoring. > - Introduced a new 'COT' build option to select the chosen chain of trust. > - Made no functional change. > See > http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03… > > Note that I've not updated the TF-A documentation just yet to reflect > these changes. I will do that once I've had some initial feedback from > the community and feel that we're reaching a consensus (in the interest > of saving time keeping documentation aligned with code going under rework). > > > Changes Compared to the Proof-of-Concept Patch [2] > -------------------------------------------------- > > - Introduced a proper, separate chain of trust rather than hijacking the > TBBR one. It also has its own header file for certificate extensions > OIDs now. > > - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short. > Going forward, this key would sign both non-trusted images (such as > BL33) and secure partitions. The NS- prefix did not fit well this use > case. The "Platform" prefix instead refers to the owner of this key, > i.e. the platform owner, as opposed to the Silicon Provider. > > - Removed Non-Trusted World Bootloader Key Certificate. > This didn't seem needed in this context and simplifies the CoT. > > - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's > not used in this CoT (the PROTPK signs all non-trusted images instead). > > - As a consequence, the corresponding option for feeding the PROTPK to > the cert_create tool has been renamed into --prot-key (was --ns-rot-key). > > - The hash of the PROTPK is now provided in a file rather than being > hard-coded into the code. This is cleaner than polluting the code with a > byte array. > > - Proper integration in the build system. > Using the dualroot chain of trust is achieved through the COT build > option: > > make <usual trusted boot build options> COT=dualroot > > - plat_get_rotpk_info() is unchanged if using the TBBR CoT. > The alternative implementation managing both ROTPK or PROTPK is > selected only if the dualroot CoT has been chosen at build time. > > > Testing and Supported Platforms > ------------------------------- > > Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states), > rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on > https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…). > > Arm Juno is not supported right now because it has its own > implementation of plat_get_arm_rotpk_info() instead of piggy-backing on > the Arm common one. > > Ran the standard set of tests available in the TF-A-Tests repository: > http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ > > Also ran the firmware update tests available in the same repository. See > > https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns… > for more information. > > Finally, performed some end-to-end boot tests to Linux. > > And of course, ran our regression tests to make sure that existing > configurations using the TBBR chain of trust are still working as expected. > > > Caveats > ------- > > The PROTPK hash is embedded into the firmware. It's unlikely that a real > system would like to do that. The use case targeted here is to remove > the need for the primary ROTPK owner to interact with the PROTPK owner. > If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner > (which is expected to be the primary ROTPK owner) has to get the PROTPK > from the other vendor. > > In a real system, we would expect the PROTPK to be provisioned in such a > way that BL2 is able to retrieve it. For example, the PROTPK owner might > burn it (or a hash of it) in some OTP memory. As long as there is a > defined contract between BL2 and the PROTK-rooted images as to how/where > to securely get this key or hash, there should not be any need for the > two vendors to do any cross-signing. > > This caveat was already present in the proof-of-concept [2] and stays > out of the scope for this work, as this ties into broader topics such as > key provisioning. Right now, the onus is on the platform layer to handle > this appropriately. > > > Future work > ----------- > > We have plans to change the "dualroot" CoT further and extend the PROTPK > signing domain with a secure partition. This would demonstrate the use > of several secure partitions, some owned by the silicon provider, others > owned by the platform owner. > > > Regards, > Sandrine >

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A