- TF-A - lists.trustedfirmware.org

Re-scheduling TF-A Tech Forum earlier by 1 hour

by Bill Fletcher

Hi all, Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to 1600 UK time (1500 UTC). This change is to avoid overlapping with the TF Technical Steering Committee call. We'll delete the existing invite and send a new one to this list. Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

4 years, 11 months

1
0
0 0

ATF LTS version

by Varun Wadekar

Hello team, To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won't have to upgrade the entire firmware to get these goodies. It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? -Varun

4 years, 11 months

1
0
0 0

Measured Boot in TF-A

by Alexei Fedorov

Hello all, The initial patch for Measured Boot has been split into 5 separates buildable ones: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4473 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4508 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4509 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4510 and are ready for review/merge. The design follows "TF-A Design Notes for Measured Boot" document . The number of API changes and code modifications based on the received feedback were made, and the most important are: 1. TPM hash algorithm is now independent from the one used by Trusted Boot and can be set separately to a different value. 2. Size of Event Log is passed as a driver build option and can be tuned to meet platform specific requirements (debug/release, number of images loaded, etc.). 3. Driver accepts platform specific table of images to be loaded/measured. 4. PCR index to use for TMP records is passed in platform specific table (see above) and can be set individually for each image. Regards. Alexei

4 years, 11 months

1
0
0 0

Question on confine_index_array.h import in tf-a

by Etienne Carriere

Dear all, As part of a patchset series review (topic scmi-msg), change [1] imports confine_array_index.h header file from OP-TEE OS repository. The file originates from the open source Fuschia project, see link in commit message of [1]. As being imported for external packages, the header file inherits Fushca and OP-TEE notices. The helper function can protect some data structure from side channel attacks leveraging index indirect access overflows during speculative execution. It is not Arm copyright. It is BSD-3-Clause license. I'll add an entry in the docs/license.rst for the file. Where to locate the file? It is ok to add such a file in include/common? Does it deserve a specific lib path, like include/lib/speculconfie_array_index.h? Maybe add as include/lib/cpus/confine_array_index.h as it is CPU speculative matters? Could you help [1] review to progress? [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4055 Regards, Etienne

4 years, 11 months

1
0
0 0

Re: [TF-A] RK3399_BAUDRATE default value

by Hugh Cole-Baker

> On 6 Jun 2020, at 17:52, Heiko Stübner via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Walter, > > Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A: >> I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE >> defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot >> default value and most documentation points to a value of 1500000 for >> console. > > console baudrate on rk3399 differ a lot between boards. There are a > number using the 1.5MHz and another big number using 115200 > (including but not limited to the ChromeOS devices from the Gru line). > > Hence we have the code that selects the actual baudrate from the > devicetree attached by u-boot when calling TF-A. > > So I guess it should stay as it is right now. On the RK3399 there are currently a couple of roadblocks preventing this selection of the baudrate from the devicetree from working. Firstly in U-Boot, SPL_ATF_NO_PLATFORM_PARAM is forced on when selecting ROCKCHIP_RK3399 in Kconfig [1]. Secondly in TF-A the 64K buffer used to store the passed devicetree isn't large enough to fit some of the RK3399 device tree blobs, as I found when removing SPL_ATF_NO_PLATFORM_PARAM from U-Boot. I guess the issue in TF-A needs to be fixed first before passing the platform parameter can be enabled in U-Boot, I've submitted a TF-A patch to increase the buffer size [2]. [1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/61853a7ac7e167d90899ec4e99d2e07… [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4512 > Heiko > > >> This of course means that messages printed by ATF are not visible by >> default in this context. >> >> The change from 1500000 to 115200 was introduced in >> 0c05748bdebfad9fa43a80962186438bb8fbce62, >> >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… >> >> with the following message >> >> commit 0c05748bdebfad9fa43a80962186438bb8fbce62 >> Author: Caesar Wang <wxt(a)rock-chips.com> >> Date: Tue Apr 19 20:42:17 2016 +0800 >> >> rockchip: fixes for the required >> >> This patch has the following change for rk3399. >> >> * Set the uart to 115200 since the loader decide to set >> uart baud to 115200Hz. So the ATF also should set uart baud to 115200. >> [..] >> >> However, I'm not sure it this still applies. >> >> I'll be happy to submit a patch to update the value if it is OK. >> >> Regards, >> >> Walter >> >> > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

2
1
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Raghu Krishnamurthy

Hello, Sorry for chiming in late. Are we sure that the msr/mrs to the GICv3 EOI register is not a context synchronizing event or ensures ordering itself ? Also did the addition of DSB() fix the issue ? If yes, can you try adding a delay or a few NOP's/dummy instructions or an ISB to see if the issue goes away? We need to know the right thing to do architecturally and confirm that the issue is really due to reordering at the core before adding the DSB. Adding a DSB might be masking a timing issue. -Raghu On 6/8/20 4:47 AM, Sandeep Tripathy via TF-A wrote: >> -----Original Message----- >> From: Soby Mathew [mailto:Soby.Mathew@arm.com] >> Sent: Monday, June 08, 2020 3:36 PM >> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org >> Cc: nd >> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC >> >> Just some inputs from my side: >> I agree we need at least a dsb() after the write to MMIO region to silence >> the >> peripheral and before the EOI at GIC sysreg interface. Adding it to the >> GIC EOI > > Thanks for the confirmation. Now it’s about choosing the right place. > >> API seems the logical thing to do but as Olivier mentions, there are >> interrupt >> handler which do not deal with MMIO (eg: the Systimer interrupt) so adding >> it >> to GICv3 API might be arduous for such handlers. >> >> So there is a choice here to let the interrupt handlers to deal with >> ensuring >> completeness before EOI at sysreg interface or adding it to GICv3 EOI API >> and >> take the overhead for interrupt handlers which do not have to deal with >> MMIO. >> > > Yes I feel either of these is a must to guarantee functionality > architecturally though > both approach end up with some unnecessary overhead. > > If GICv3 api takes care then it is an overhead for some ISRs dealing with > non-MMIO. > At present I do not see an active use case in reference implementation where > sys timer > ISR is in a performance intensive path where one additional DSB will be > perceivable. > But there may be some I could be totally wrong in this assumption (pmu/debug > or.. not sure). > Whereas I can certainly imagine some MMIO ISRs in performance critical path > where unnecessary > DSB is not acceptable at all. > > If the interrupt handler needs to ensure then it will generically add 'DSB' > as I think > the driver cannot and should not make assumptions about how EOI is done > afterwards. > That will be overhead for the ISRs dealing with MMIO peripherals and non > GIC-v3. > If we consider only GICv3+ then good. Otherwise I would prefer the > 'plat_ic_end_of_interrupt' > like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with > it. > >> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys >> interface is the only one GICv3 driver in TF-A supports. > > Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > >> >> Best Regards >> Soby Mathew >> > > Thanks > Sandeep > >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep >>> Tripathy via TF-A >>> Sent: 08 June 2020 10:34 >>> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- >> a(a)lists.trustedfirmware.org >>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC >>> >>> Hi Olivier, >>>> -----Original Message----- >>>> From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] >>>> Sent: Monday, June 08, 2020 1:14 PM >>>> To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy >>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC >>>> >>>> Hi Sandeep, >>>> >>>> gicv3_end_of_interrupt_sel1 is a static access helper macro. Its >>>> naming precisely tells what it does at gicv3 module level. It is >>>> called from >>> the weak >>>> plat_ic_end_of_interrupt function for BL32 image. >>>> >>>> I tend to think it is the driver responsibility to ensure the module >>> interrupt >>>> acknowledge register write is reaching HW in order (or "be visible to >>> all >>>> observers"). >>> >>> The driver should be agnostic of what interrupt controller is used and >>> its >>> behavior. >>> And since 'all' writes were to mmio ranges mapped Device(nGnRE) >>> /strongly-ordered(nGnRnE) >>> there was no such need. This is a special case for GICv3 system >>> interface only. >>> Adding at driver level a DSB is unnecessary for other interrupt >>> controllers. >>> >>>> Also I suspect adding a dsb might not be required generically for all >>> kind of IP. >>> >>> Here are you referring to the peripheral IP or interrupt controller IP ? >>> The issue is reordering at arm core itself (STR to device address Vs >>> msr(sysreg >>> write)). >>> So I think Its applicable for all IP. >>> >>>> Adding a barrier in generic code might incur an unnecessary >>>> bottleneck. >>> >>> But if there is a need to *ensure* presence of at least one DSB between >>> the >>> write transfer from core to device clear and gicv3 eoi icc register >>> write in a >>> generic way then what other option we have. >>>> >>>> Thus wouldn't it be better to add the barrier to the overridden >>>> platform function rather than in generic gicv3 code? >>> >>> That can be done but I feel this is more to do with gicv3 system >>> interface only. >>> Inside plat_xxx one has to check #if GICV3 ...and system interface. >>>> >>>> I have a put a comment in the review, we can continue the discussion >>> there. >>>> >>>> Regards, >>>> Olivier. >>>> >>> Thanks >>> Sandeep >>>> ________________________________________ >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of >>>> Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> >>>> Sent: 05 June 2020 19:43 >>>> To: tf-a(a)lists.trustedfirmware.org >>>> Subject: [TF-A] GICV3: system interface EOI ordering RFC >>>> >>>> Hi, >>>> In a typical interrupt handling sequence we do 1-Read IAR >>>> 2-Do interrupt handling >>>> 3-Clear the interrupt at source , so that the device de-asserts IRQ >>> request to >>>> GIC >>>> >> I am suggesting a need of DSB here in case of GICv3 +. >>>> 4-Write to GIC cpu interface to do EOI. >>>> >>>> Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write >>>> over >>> AMBA >>>> interface. The >>>> Addresses are mapped with (nR) attribute. Hence the write transfers >>> from the >>>> core will be >>>> generated at step 3 and 4 in order. Please ignore the additional >>> buffers/bridges >>>> in path from >>>> core till peripheral which has to be dealt separately as per SOC. >>>> >>>> Query: I understand GICv3 system interface accesses are not over this >>> protocol >>>> and core will not >>>> follow the ordering rule ? >>>> >>>> I have observed spurious interrupt issue/manifestation ( I don't have >>> the >>>> transfers probed) in >>>> RTOS environment where I have a primitive GICv3 driver but I wonder >>>> why things does not fail in Linux or tf-a. If it is working because >>>> from step(3) to >>> step(4) we have >>>> barriers by chace >>>> due to other device register writes then I would suggest to have one >>>> in >>> the EOI >>>> clearing API itself. >>>> >>>> RFC: >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 >>>> >>>> Thanks >>>> Sandeep >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

> -----Original Message----- > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > Sent: Monday, June 08, 2020 3:36 PM > To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org > Cc: nd > Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC > > Just some inputs from my side: > I agree we need at least a dsb() after the write to MMIO region to silence > the > peripheral and before the EOI at GIC sysreg interface. Adding it to the > GIC EOI Thanks for the confirmation. Now it’s about choosing the right place. > API seems the logical thing to do but as Olivier mentions, there are > interrupt > handler which do not deal with MMIO (eg: the Systimer interrupt) so adding > it > to GICv3 API might be arduous for such handlers. > > So there is a choice here to let the interrupt handlers to deal with > ensuring > completeness before EOI at sysreg interface or adding it to GICv3 EOI API > and > take the overhead for interrupt handlers which do not have to deal with > MMIO. > Yes I feel either of these is a must to guarantee functionality architecturally though both approach end up with some unnecessary overhead. If GICv3 api takes care then it is an overhead for some ISRs dealing with non-MMIO. At present I do not see an active use case in reference implementation where sys timer ISR is in a performance intensive path where one additional DSB will be perceivable. But there may be some I could be totally wrong in this assumption (pmu/debug or.. not sure). Whereas I can certainly imagine some MMIO ISRs in performance critical path where unnecessary DSB is not acceptable at all. If the interrupt handler needs to ensure then it will generically add 'DSB' as I think the driver cannot and should not make assumptions about how EOI is done afterwards. That will be overhead for the ISRs dealing with MMIO peripherals and non GIC-v3. If we consider only GICv3+ then good. Otherwise I would prefer the 'plat_ic_end_of_interrupt' like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with it. > The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys > interface is the only one GICv3 driver in TF-A supports. Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > > Best Regards > Soby Mathew > Thanks Sandeep > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 08 June 2020 10:34 > > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi Olivier, > > > -----Original Message----- > > > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > > > Sent: Monday, June 08, 2020 1:14 PM > > > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > > > Hi Sandeep, > > > > > > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > > > naming precisely tells what it does at gicv3 module level. It is > > > called from > > the weak > > > plat_ic_end_of_interrupt function for BL32 image. > > > > > > I tend to think it is the driver responsibility to ensure the module > > interrupt > > > acknowledge register write is reaching HW in order (or "be visible to > > all > > > observers"). > > > > The driver should be agnostic of what interrupt controller is used and > > its > > behavior. > > And since 'all' writes were to mmio ranges mapped Device(nGnRE) > > /strongly-ordered(nGnRnE) > > there was no such need. This is a special case for GICv3 system > > interface only. > > Adding at driver level a DSB is unnecessary for other interrupt > > controllers. > > > > > Also I suspect adding a dsb might not be required generically for all > > kind of IP. > > > > Here are you referring to the peripheral IP or interrupt controller IP ? > > The issue is reordering at arm core itself (STR to device address Vs > > msr(sysreg > > write)). > > So I think Its applicable for all IP. > > > > > Adding a barrier in generic code might incur an unnecessary > > > bottleneck. > > > > But if there is a need to *ensure* presence of at least one DSB between > > the > > write transfer from core to device clear and gicv3 eoi icc register > > write in a > > generic way then what other option we have. > > > > > > Thus wouldn't it be better to add the barrier to the overridden > > > platform function rather than in generic gicv3 code? > > > > That can be done but I feel this is more to do with gicv3 system > > interface only. > > Inside plat_xxx one has to check #if GICV3 ...and system interface. > > > > > > I have a put a comment in the review, we can continue the discussion > > there. > > > > > > Regards, > > > Olivier. > > > > > Thanks > > Sandeep > > > ________________________________________ > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > > > Sent: 05 June 2020 19:43 > > > To: tf-a(a)lists.trustedfirmware.org > > > Subject: [TF-A] GICV3: system interface EOI ordering RFC > > > > > > Hi, > > > In a typical interrupt handling sequence we do 1-Read IAR > > > 2-Do interrupt handling > > > 3-Clear the interrupt at source , so that the device de-asserts IRQ > > request to > > > GIC > > > >> I am suggesting a need of DSB here in case of GICv3 +. > > > 4-Write to GIC cpu interface to do EOI. > > > > > > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > > > over > > AMBA > > > interface. The > > > Addresses are mapped with (nR) attribute. Hence the write transfers > > from the > > > core will be > > > generated at step 3 and 4 in order. Please ignore the additional > > buffers/bridges > > > in path from > > > core till peripheral which has to be dealt separately as per SOC. > > > > > > Query: I understand GICv3 system interface accesses are not over this > > protocol > > > and core will not > > > follow the ordering rule ? > > > > > > I have observed spurious interrupt issue/manifestation ( I don't have > > the > > > transfers probed) in > > > RTOS environment where I have a primitive GICv3 driver but I wonder > > > why things does not fail in Linux or tf-a. If it is working because > > > from step(3) to > > step(4) we have > > > barriers by chace > > > due to other device register writes then I would suggest to have one > > > in > > the EOI > > > clearing API itself. > > > > > > RFC: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > > > > > > Thanks > > > Sandeep > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Soby Mathew

Just some inputs from my side: I agree we need atleast a dsb() after the write to MMIO region to silence the peripheral and before the EOI at GIC sysreg interface. Adding it to the GIC EOI API seems the logical thing to do but as Olivier mentions, there are interrupt handler which do not deal with MMIO (eg: the Systimer interrupt) so adding it to GICv3 API might be arduous for such handlers. So there is a choice here to let the interrupt handlers to deal with ensuring completeness before EOI at sysreg interface or adding it to GICv3 EOI API and take the overhead for interrupt handlers which do not have to deal with MMIO. The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys interface is the only one GICv3 driver in TF-A supports. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 08 June 2020 10:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > Hi Olivier, > > -----Original Message----- > > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > > Sent: Monday, June 08, 2020 1:14 PM > > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi Sandeep, > > > > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > > naming precisely tells what it does at gicv3 module level. It is > > called from > the weak > > plat_ic_end_of_interrupt function for BL32 image. > > > > I tend to think it is the driver responsibility to ensure the module > interrupt > > acknowledge register write is reaching HW in order (or "be visible to > all > > observers"). > > The driver should be agnostic of what interrupt controller is used and its > behavior. > And since 'all' writes were to mmio ranges mapped Device(nGnRE) > /strongly-ordered(nGnRnE) > there was no such need. This is a special case for GICv3 system interface only. > Adding at driver level a DSB is unnecessary for other interrupt controllers. > > > Also I suspect adding a dsb might not be required generically for all > kind of IP. > > Here are you referring to the peripheral IP or interrupt controller IP ? > The issue is reordering at arm core itself (STR to device address Vs msr(sysreg > write)). > So I think Its applicable for all IP. > > > Adding a barrier in generic code might incur an unnecessary bottleneck. > > But if there is a need to *ensure* presence of at least one DSB between the > write transfer from core to device clear and gicv3 eoi icc register write in a > generic way then what other option we have. > > > > Thus wouldn't it be better to add the barrier to the overridden > > platform function rather than in generic gicv3 code? > > That can be done but I feel this is more to do with gicv3 system interface only. > Inside plat_xxx one has to check #if GICV3 ...and system interface. > > > > I have a put a comment in the review, we can continue the discussion > there. > > > > Regards, > > Olivier. > > > Thanks > Sandeep > > ________________________________________ > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > > Sent: 05 June 2020 19:43 > > To: tf-a(a)lists.trustedfirmware.org > > Subject: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi, > > In a typical interrupt handling sequence we do 1-Read IAR > > 2-Do interrupt handling > > 3-Clear the interrupt at source , so that the device de-asserts IRQ > request to > > GIC > > >> I am suggesting a need of DSB here in case of GICv3 +. > > 4-Write to GIC cpu interface to do EOI. > > > > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > > over > AMBA > > interface. The > > Addresses are mapped with (nR) attribute. Hence the write transfers > from the > > core will be > > generated at step 3 and 4 in order. Please ignore the additional > buffers/bridges > > in path from > > core till peripheral which has to be dealt separately as per SOC. > > > > Query: I understand GICv3 system interface accesses are not over this > protocol > > and core will not > > follow the ordering rule ? > > > > I have observed spurious interrupt issue/manifestation ( I don't have > the > > transfers probed) in > > RTOS environment where I have a primitive GICv3 driver but I wonder > > why things does not fail in Linux or tf-a. If it is working because > > from step(3) to > step(4) we have > > barriers by chace > > due to other device register writes then I would suggest to have one > > in > the EOI > > clearing API itself. > > > > RFC: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > > > > Thanks > > Sandeep > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Olivier Deprez

Hi Sandeep, gicv3_end_of_interrupt_sel1 is a static access helper macro. Its naming precisely tells what it does at gicv3 module level. It is called from the weak plat_ic_end_of_interrupt function for BL32 image. I tend to think it is the driver responsibility to ensure the module interrupt acknowledge register write is reaching HW in order (or "be visible to all observers"). Also I suspect adding a dsb might not be required generically for all kind of IP. Adding a barrier in generic code might incur an unnecessary bottleneck. Thus wouldn't it be better to add the barrier to the overridden platform function rather than in generic gicv3 code? I have a put a comment in the review, we can continue the discussion there. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 05 June 2020 19:43 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] GICV3: system interface EOI ordering RFC Hi, In a typical interrupt handling sequence we do 1-Read IAR 2-Do interrupt handling 3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC >> I am suggesting a need of DSB here in case of GICv3 +. 4-Write to GIC cpu interface to do EOI. Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from core till peripheral which has to be dealt separately as per SOC. Query: I understand GICv3 system interface accesses are not over this protocol and core will not follow the ordering rule ? I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in RTOS environment where I have a primitive GICv3 driver but I wonder why things does not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace due to other device register writes then I would suggest to have one in the EOI clearing API itself. RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 Thanks Sandeep

4 years, 11 months

2
1
0 0

Re: [TF-A] RK3399_BAUDRATE default value

by Heiko Stübner

Hi Walter, Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A: > I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE > defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot > default value and most documentation points to a value of 1500000 for > console. console baudrate on rk3399 differ a lot between boards. There are a number using the 1.5MHz and another big number using 115200 (including but not limited to the ChromeOS devices from the Gru line). Hence we have the code that selects the actual baudrate from the devicetree attached by u-boot when calling TF-A. So I guess it should stay as it is right now. Heiko > This of course means that messages printed by ATF are not visible by > default in this context. > > The change from 1500000 to 115200 was introduced in > 0c05748bdebfad9fa43a80962186438bb8fbce62, > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… > > with the following message > > commit 0c05748bdebfad9fa43a80962186438bb8fbce62 > Author: Caesar Wang <wxt(a)rock-chips.com> > Date: Tue Apr 19 20:42:17 2016 +0800 > > rockchip: fixes for the required > > This patch has the following change for rk3399. > > * Set the uart to 115200 since the loader decide to set > uart baud to 115200Hz. So the ATF also should set uart baud to 115200. > [..] > > However, I'm not sure it this still applies. > > I'll be happy to submit a patch to update the value if it is OK. > > Regards, > > Walter > >

4 years, 11 months

1
0
0 0

RK3399_BAUDRATE default value

by Walter Lozano

I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot default value and most documentation points to a value of 1500000 for console. This of course means that messages printed by ATF are not visible by default in this context. The change from 1500000 to 115200 was introduced in 0c05748bdebfad9fa43a80962186438bb8fbce62, https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… with the following message commit 0c05748bdebfad9fa43a80962186438bb8fbce62 Author: Caesar Wang <wxt(a)rock-chips.com> Date: Tue Apr 19 20:42:17 2016 +0800 rockchip: fixes for the required This patch has the following change for rk3399. * Set the uart to 115200 since the loader decide to set uart baud to 115200Hz. So the ATF also should set uart baud to 115200. [..] However, I'm not sure it this still applies. I'll be happy to submit a patch to update the value if it is OK. Regards, Walter

4 years, 11 months

1
0
0 0

GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

Hi, In a typical interrupt handling sequence we do 1-Read IAR 2-Do interrupt handling 3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC >> I am suggesting a need of DSB here in case of GICv3 +. 4-Write to GIC cpu interface to do EOI. Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from core till peripheral which has to be dealt separately as per SOC. Query: I understand GICv3 system interface accesses are not over this protocol and core will not follow the ordering rule ? I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in RTOS environment where I have a primitive GICv3 driver but I wonder why things does not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace due to other device register writes then I would suggest to have one in the EOI clearing API itself. RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 Thanks Sandeep

4 years, 11 months

1
0
0 0

Re: [TF-A] Slides for recent TF-A Forums

by Joanna Farley

Hi Okash, These are generally provided on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ however they are missing from 7th May onwards at the moment. I have an update pending approval on tf.org for adding the details of that session and then I need to add the information from the session on 21st May and the session yesterday. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Okash Khawaja via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Okash Khawaja <okash.khawaja(a)gmail.com> Date: Friday, 5 June 2020 at 11:29 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Slides for recent TF-A Forums Hi, Where can I find slides for recent TF-A Forum presentations? Thanks, Okash

4 years, 11 months

1
0
0 0

Slides for recent TF-A Forums

by Okash Khawaja

Hi, Where can I find slides for recent TF-A Forum presentations? Thanks, Okash

4 years, 11 months

1
0
0 0

Re: [TF-A] Gerrit seems to be broken

by Madhukar Pappireddy

Hi Bill, I continue to the error while trying to invoke “Allow-CI” or other votes as part of gerrit review. I tried multiple browsers as well and logged out before attempting again. Thanks, Madhu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-A Sent: Tuesday, June 2, 2020 12:13 PM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Gerrit seems to be broken Hi Varun, Do you still see the problem? It has been reported before. Regards Bill On Tue, 2 Jun 2020 at 18:01, Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hello, The TF gerrit review dashboard seems to be broken this morning. I see “Server error” and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [Image removed by sender. Linaro]<http://www.linaro.org/> Bill Fletcher | Field Engineering T: +44 7833 498336<tel:+44+7833+498336> bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020

4 years, 11 months

3
4
0 0

Re: [TF-A] Gerrit seems to be broken

by Bill Fletcher

Hi Varun, Do you still see the problem? It has been reported before. Regards Bill On Tue, 2 Jun 2020 at 18:01, Varun Wadekar via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hello, > > > > The TF gerrit review dashboard seems to be broken this morning. I see > “Server error” and it does not allow me to post scores or comments. Tried > different browsers, but same issue persists. > > > > Anyone else seeing the same problem? Is this is a known issue? If yes, is > anyone working on it? > > > > -Varun > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

4 years, 11 months

1
0
0 0

Re: [TF-A] Gerrit seems to be broken

by Joanna Farley

Working for me, the main and additional dashboards. https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a,dash… I posted comments earlier ok as well. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Varun Wadekar <vwadekar(a)nvidia.com> Date: Tuesday, 2 June 2020 at 18:02 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Gerrit seems to be broken Hello, The TF gerrit review dashboard seems to be broken this morning. I see “Server error” and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun

4 years, 11 months

1
0
0 0

Gerrit seems to be broken

by Varun Wadekar

Hello, The TF gerrit review dashboard seems to be broken this morning. I see "Server error" and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun

4 years, 11 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 4th June 2020 17:00-1800 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 4th June 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: * TF-A SMC fuzzing module overview - Presented by Mark Dykes * General explanation of the approach taken to randomize the type and timing of the SMC calls in TF-A to provide a Fuzz testing capability. * Optional TF-A Mailing List Topic Discussions Thanks Joanna

4 years, 11 months

1
0
0 0

Re: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Manish Badarkhe

Hi Andrzej I think recent patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 which is currently in review may be solution for your issue where SCU presence is being checked before accessing CLUSTERCFR_EL1 register. Thanks Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of "Witkowski, Andrzej via TF-A" <tf-a(a)lists.trustedfirmware.org> Reply to: "Witkowski, Andrzej" <andrzej.witkowski(a)intel.com> Date: Monday, 1 June 2020 at 19:38 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Cc: "Witkowski, Andrzej" <andrzej.witkowski(a)intel.com>, "Lessnau, Adam" <adam.lessnau(a)intel.com> Subject: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error “Unhandled Exception at EL3” in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D6384E.C183C050] [cid:image002.png@01D6384E.C183C050] Neoverse N1 with direct connect version of DSU doesn’t contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error “Unhandled Exception at EL3” appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn’t exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN. Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

4 years, 11 months

1
0
0 0

Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Witkowski, Andrzej

Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error "Unhandled Exception at EL3" in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D63828.FA4B1440] [cid:image002.png@01D6382A.B84A0950] Neoverse N1 with direct connect version of DSU doesn't contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error "Unhandled Exception at EL3" appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn't exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

4 years, 11 months

1
0
0 0

Announcing new maintainers for the TF-A project

by Sandrine Bailleux

Hi all, Now that the tf.org project maintenance process [1] has been finalized, it is time to think about electing new maintainers for the project. We are delighted to announce that the following contributors have been appointed maintainers by their peers: - Julius Werner (Google) - Varun Wadekar (NVIDIA) - Andre Przywara (Arm) - Lauren Wehrmeister (Arm) - Madhukar Pappireddy (Arm) As outlined in [1], here is the definition and responsibilities of maintainers: ------------8<------------ There are a number of maintainers assigned to the project. The project keeps a list of them along with their contact information. Maintainers don't necessarily need a deep domain expertise of all areas of the project, instead they look at the project from a high level perspective. They are expected to ensure that changes adhere to the project's quality criteria, to its architectural direction, to its threat model and so on. Code owners and maintainers are complementary roles. Unlike code owners, maintainers can approve any patch, no matter what module it concerns. They are responsible for ensuring patches have had enough overall review and adding their own approval in a timely manner. They also have merge rights, i.e. the ability to merge a patch in the tree once it has received all required approvals. ------------8<------------ These people have been granted Code-Review -2/+2 rights in Gerrit and have been added in the maintainers.rst file as part of this patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4298 Congratulations to them! Best regards, Sandrine [1] https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…

4 years, 11 months

1
0
0 0

Re: [TF-A] After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs.

by Manish Pandey2

Hi Pankaj, Can you please send the specific NOTICE messages which are missing, may be sending 1.5 and 2.3 logs will help. thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 May 2020 09:36 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs. Hi After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs. Any pointers on how to fix this issue. Thanks. Regards Pankaj

4 years, 11 months

1
0
0 0

After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs.

by Pankaj Gupta

Hi After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs. Any pointers on how to fix this issue. Thanks. Regards Pankaj

4 years, 11 months

1
0
0 0

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

by Manish Badarkhe

Hi Raghu We have plan to work on this and come up with some design which handles mandatory/critical properties. On 13/05/2020, 22:18, "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 All, Since the 2.3 release is done, can we revisit this topic? I think we left this with finalizing on how to handle bad/incorrect DTB's. Sandrine's latest proposal below: "A bad DTB seems more like an integration error than a programming error to me, and thus should be handled with runtime checks according to the current guidelines. Incorrect values for mandatory properties should probably be treated as unrecoverable errors (causing a panic) and incorrect/missing optional properties as recoverable errors (issuing a warning message)." I agree with this proposal and think we should follow this. This addresses my original concern of handling errors consistently and being safe by verifying mandatory/critical properties at run-time. Thoughts ? Thanks Raghu On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote: > Thanks Sandrine. Revisiting after v2.3 is sounds fine. > > -Raghu > > On 4/10/20 2:25 AM, Sandrine Bailleux wrote: >> Hi Raghu, >> >> On 4/8/20 12:50 AM, Raghu Krishnamurthy wrote: >>> Thanks Sandrine, Louis, >>> >>> Agree with both of you. I'm fine with using asserts or panics, as >>> long as we uniformly use it. The change i sent out(review 3845) was >>> because i noticed inconsistency in handling errors. If we do use >>> asserts, all code that checks for mandatory properties, should be >>> changed to assert as opposed to return error code. For optional >>> properties, we can continue to return an error code or print >>> warnings etc. >> >> Yes, I too think consistency is key here. As you said, we need to >> settle on the expected behaviour and enforce it uniformly across the >> fconf code. Let's revisit this code after the v2.3 release. >> >>> I would like to point out that using asserts here is different from >>> what is documented in the coding guidelines. The guidelines >>> explicitly spells out using asserts for "programming errors". >>> Now, is having a bad DTB considered a programming error? ;) The DTB >>> is platform data as opposed to code. The guidelines might need to be >>> updated based on the conclusion here. >> >> Now that you point it out, and after taking a closer look at [1], I >> think I was wrong. A bad DTB seems more like an integration error >> than a programming error to me, and thus should be handled with >> runtime checks according to the current guidelines. Incorrect values >> for mandatory properties should probably be treated as unrecoverable >> errors (causing a panic) and incorrect/missing optional properties as >> recoverable errors (issuing a warning message). >> >> [1] >> https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline… >> >> >>> Also note the couple of scenarios i mentioned in an earlier email. >>> Platforms like RPI4 don't generally enable TBBR and the DTB image >>> could get corrupt or be modified on purpose. On a release build, >>> this could cause silent corruption. Panic() would avoid this. >>> >>> In any case, it would be good to settle on the expected behavior for >>> each of these abnormal cases. I don't have a strong preference for >>> asserts or panics here, since each has its pros and cons as both of >>> you called out. >>> >>> Thanks >>> Raghu > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 12 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 21sth May 2020 17:00-1800 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 21st May 2020 17:00 - 18:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Firmware Configuration Framework (FConf) Update - Presented by Manish Badarkhe and Madhukar Pappireddy * Discussion on how we have leveraged FConf framework in making statically configured components of TF-A to be dynamic. A number of such components have already been identified which potentially use FConf framework. Patches for such components are either merged or in-review * Design discussion on CoT descriptors movement to device tree using FConf framework. * Optional TF-A Mailing List Topic Discussions Thanks Joanna

4 years, 12 months

1
0
0 0

Re: [TF-A] Candidates for fconf based dynamic configuration

by Raghu K

Off the top of my head, secure world interrupts(SPI's, PPI's, SGI's), MMU mappings for anything that does not depend on image layout(platform specific devices, UEFI MM or other special regions), security policies like TZC region protections. -Raghu On 5/14/20 8:45 AM, Madhukar Pappireddy via TF-A wrote: > > Hi, > > We are in the process of leveraging the fconf framework to make the > static configurations of various components of TF-A to more dynamic > configurations. The primary motivation behind this effort is to > evaluate the possibility of having common TF-A BL images that can be > used across multiple platforms. As a start, this involves moving > compile-time C based data structures into device tree which are > extracted during runtime. We have chosen the FVP platform as a proof > of concept for this effort and have identified the following > components to be made more dynamic: > > runtime UART std-out: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3775, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3923/ > > Topology description: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3522 > > GICv3 configuration: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4066 > > Timer configuration: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3696 > > SDEI platform setup: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3990 > > CoT descriptor: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4080, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4081 > > Platform IO Policies: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2558 > > Please advise if there are any other components of TF-A that can be > configured dynamically in runtime. > > Thanks, > > Madhu > >

5 years

1
0
0 0

Candidates for fconf based dynamic configuration

by Madhukar Pappireddy

Hi, We are in the process of leveraging the fconf framework to make the static configurations of various components of TF-A to more dynamic configurations. The primary motivation behind this effort is to evaluate the possibility of having common TF-A BL images that can be used across multiple platforms. As a start, this involves moving compile-time C based data structures into device tree which are extracted during runtime. We have chosen the FVP platform as a proof of concept for this effort and have identified the following components to be made more dynamic: runtime UART std-out: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3775, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3923/ Topology description: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3522 GICv3 configuration: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4066 Timer configuration: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3696 SDEI platform setup: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3990 CoT descriptor: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4080, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4081 Platform IO Policies: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2558 Please advise if there are any other components of TF-A that can be configured dynamically in runtime. Thanks, Madhu

5 years

1
0
0 0

Re: [TF-A] TF-A and U-Boot: How to Boot a specific u-boot image

by Raghu K

Hi Florian, I can give some general answers to your questions and hopefully get to answering your real questions with further discussion. Please feel free to ask more questions if this does not help. >> I noticed that TF-A is designed to load FIP Image but the U-Boot Environment have a different format. How to access the QSPI NOR memory? NXP specific driver? [RK] TF-A generally provides frameworks to do most things and does not provide device specific drivers but for SPI NOR, there are drivers under drivers/mtd/nor that could potentially be used. You will likely need to implement the appropriate platform hooks for the SPI bus itself to use it. The TF-A IO framework has the io_mtd layer that can be hooked into a nor device. drivers/st/spi/stm32_qspi.c seems to use all of this and should be a good example(perhaps some one from ST can chime in too). if you hook you SPI driver to the TF-A layers correctly, there should be nothing preventing you from accessing the uboot environment partition. Also, TF-A's primary/default format for firmware images is FIP but definitely does not preclude a platform from using it's own format. >>The bl2 is designed to load only one FIP image, is it possible to add an additional entry ? [RK] Not really. BL2 is fairly generic and you should be able to hook any image format to it. If you must use the FIP format, you can map your images to existing image id's to create a FIP with any image that you have. Once again, FIP is fairly flexible and generally treats firmware images in the package as blob's. >>if we want to use a secure boot in the future [RK] Like with the above things, the Trusted Board Boot framework is flexible and you should be able to implement secure boot on FIP and other formats. TF-A provides an implementation of the TBBR specification for secure boot. It should be possible to implement the algorithm below, if you have an appropriate platform port, from what i gather in your question below. Thanks -Raghu On 5/13/20 5:40 AM, florian.manoel--- via TF-A wrote: > > Hello TF-A mail list, > > I’m new here, so I quickly introduce myself. > I am Florian Manoel, working as firmware developer at Siemens in > Karlsruhe, Germany. Recently, we decided to start some development > based on ARM processor, the theme TF-A is new for us. > > Currently, we have a custom board equipped with the processor NXP > Layerscape LS1043a. So far, everything is working as planned, the > PreBootLoader (TF-A) boots the bootloader (U-Boot) that’s boots linux > on top. > However, we want to have the possibility to boot an alternative u-boot > FIP image, I explain: > We use as boot source a QSPI NOR memory. In this memory are stored > ‘bl2_qspi.pbl’, 2 times ‘fip.bin’, the u-boot environment and some > micro-code. > We want to select the u-boot image to be booted according to the value > of a specific variable stored in the u-boot environment ‘u-boot-select’. > The algo is, for my eye, relatively simple : > > Start > - Check value of the u-boot variable ‘u-boot-select’ > > - Check if the corresponding u-boot image is valid, if not select the > alternative one > - Boot selected u-boot image > End > > > We want this functionality in case an u-boot image is broken (ex: > power OFF during U-Boot update). > > I already went through the source code and it rose more question than > it answered. For example: > I noticed that TF-A is designed to load FIP Image but the U-Boot > Environment have a different format. How to access the QSPI NOR > memory? NXP specific driver? > The bl2 is designed to load only one FIP image, is it possible to add > an additional entry ? > On top of it come the question of the reliability and what will happen > if we want to use a secure boot in the future.. > > I am looking for advice and support on this specific topic. > Thanks for your support, > > Mit freundlichen Grüßen > Florian Manoël > > Siemens AG > Digital Industries > Process Automation > Software House Khe > DI PA CI R&D 2 > Östliche Rheinbrückenstr. 50 > 76187 Karlsruhe, Deutschland > Tel.: +49 721 595-1433 > mailto:florian.manoel@siemens.com > www.siemens.com/ingenuityforlife <https://siemens.com/ingenuityforlife> > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim > Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, > Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: > Berlin und München, Deutschland; Registergericht: Berlin > Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322 > >

5 years

1
0
0 0

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

by Sandrine Bailleux

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

5 years

3
4
0 0

TF-A and U-Boot: How to Boot a specific u-boot image

by florian.manoel＠siemens.com

Hello TF-A mail list, I'm new here, so I quickly introduce myself. I am Florian Manoel, working as firmware developer at Siemens in Karlsruhe, Germany. Recently, we decided to start some development based on ARM processor, the theme TF-A is new for us. Currently, we have a custom board equipped with the processor NXP Layerscape LS1043a. So far, everything is working as planned, the PreBootLoader (TF-A) boots the bootloader (U-Boot) that's boots linux on top. However, we want to have the possibility to boot an alternative u-boot FIP image, I explain: We use as boot source a QSPI NOR memory. In this memory are stored 'bl2_qspi.pbl', 2 times 'fip.bin', the u-boot environment and some micro-code. We want to select the u-boot image to be booted according to the value of a specific variable stored in the u-boot environment 'u-boot-select'. The algo is, for my eye, relatively simple : Start - Check value of the u-boot variable 'u-boot-select' - Check if the corresponding u-boot image is valid, if not select the alternative one - Boot selected u-boot image End We want this functionality in case an u-boot image is broken (ex: power OFF during U-Boot update). I already went through the source code and it rose more question than it answered. For example: I noticed that TF-A is designed to load FIP Image but the U-Boot Environment have a different format. How to access the QSPI NOR memory? NXP specific driver? The bl2 is designed to load only one FIP image, is it possible to add an additional entry ? On top of it come the question of the reliability and what will happen if we want to use a secure boot in the future.. I am looking for advice and support on this specific topic. Thanks for your support, Mit freundlichen Grüßen Florian Manoël Siemens AG Digital Industries Process Automation Software House Khe DI PA CI R&D 2 Östliche Rheinbrückenstr. 50 76187 Karlsruhe, Deutschland Tel.: +49 721 595-1433 mailto:florian.manoel@siemens.com www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

5 years

1
0
0 0

Impact of the tf.org projects' maintenance process on TF-A

by Sandrine Bailleux

Hello all, As the trustedfirmware.org project maintenance process [1] is now live, it would be good if we start adopting it in our development flow for TF-A. I would like to highlight the main changes that will have an impact on our day-to-day work on the project. 1. Patch submitters to explicit choose their reviewers ------------------------------------------------------ All patches should now have dedicated reviewers. The patch submitter is responsible for adding them in the reviewers field of their Gerrit review. Each patch should have 2 types of reviewers: - Code owners. - Maintainers. There needs to be 1 code owner per module modified by the patch as well as 1 maintainer. The maintainers and code owners are listed here: https://trustedfirmware-a.readthedocs.io/en/latest/about/maintainers.html Ideally, we would have at least 2 code owners per module so that they can review each other's patches. Unfortunately we're not there yet (especially for platform ports) so we need a work around for patches submitted by the sole code owner of a module itself. In this scenario, I would like to suggest we leave it to the patch submitter to decide on a case by case basis whether they want to nominate someone to do the detailed technical review or skip it entirely. In any case, a maintainer will still need to review and approve the patch. If this proves not to be working well over time (either because it creates unnecessary review bottlenecks or lowers the code quality too much), we can revisit that in the future. If you've got patches in review right now, may I please request you to add reviewers accordingly? The sooner we start adopting this process the better, as it will allow us to see how this works in practice and come up with adjustments if need be. 2. Reviewers to provide feedback in a timely manner --------------------------------------------------- If someone asks you to do a review, please try to do it in a timely manner. There is no timeline guidelines set just yet for TF-A but I think a good rule of thumb would be to aim to provide feedback in a week's time. This does not mean that the review has to be completed in a week (complex patches might need a lot of discussion and/or rounds of review & rework), just that there's some progress and activity at least once per week. If for some reason, you know you won't be able to honour a review request, please say so on Gerrit ASAP so that the patch submitter can choose another reviewer. 3. What's next? --------------- In the coming weeks or months, we'd like to: - Extend the list of code owners. - Extend the list of maintainers. - Come up with TF-A specific contribution guidelines that complement the tf.org process [1]. We already have some here [2] but would like to expand them and possibly revisit some of them. Obviously, this will be a community effort, much like the tf.org process was, and all TF-A contributors will have a say in defining this so that we end up with something that works for everyone (as much as possible). Best regards, Sandrine [1] https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… [2] https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html

5 years

1
0
0 0

Re: [TF-A] GCC compiler flags

by Samuel Holland

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

5 years

1
0
0 0

GCC compiler flags

by Varun Wadekar

Hello, While reviewing all the compiler flags used by TF-A, we couldn't find information for the following options in the GCC manual [1] * --fatal-warnings (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) * -fno-stack-protector (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…) Can someone please help me understand if these options are still valid? Thanks. [1] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Option-Index.html#Option-Index ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years

1
0
0 0

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

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > I've received very little feedback on version 2 of the proposal, which > hints that we are reaching an agreement. Thus, I plan to finalize the > proposal this week. This can then become part of our development flow > for all trustedfirmware.org projects. > > Thanks again for all the inputs! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

5 years

1
0
0 0

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

by scan-admin＠coverity.com

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

5 years

1
0
0 0

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

by Vivek Prasad

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

5 years

3
3
0 0

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

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 7th May 2020 17:00 - 18:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. This meeting will be chaired by Bipin Ravi. Agenda: * Overview of a new TF-A Build System based on Cmake by Javier Almansa Sobrino * Optional TF-A Mailing List Topic Discussions Thanks Joanna

5 years

1
0
0 0

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

by Soby Mathew

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

5 years

3
6
0 0

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

by Sandrine Bailleux

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

5 years

1
0
0 0

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

by Achin Gupta

Hi Francois, On Mon, Apr 20, 2020 at 11:45:02AM +0000, François Ozog via TF-A wrote: > Hi, > > I am trying to identify a mechanism to enforce a form of two-way > isolation between BL33 runtime services in OS, for instance: > - a pair of 2MB areas that could be RO by one entity and RW by the other > - an execute only BL33 2MB area? Stupid Q! Are you referring to isolation between EFI runtime services and the OS? It is not clear what you mean by BL33 runtime services? cheers, Achin > > This is similar to hypervisor except it only deals with memory, no > vCPU, no GIC virtualization... > > Could EL3 or EL2 install protective mappings ? BL33 could ask either > EL2 hypervisor or SecureMonitor to actually install them. > > Cordially, > > FF > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A