- TF-A - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
0
0 0

GCC compiler flags

by Varun Wadekar

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

5 years, 5 months

1
0
0 0

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

by Sandrine Bailleux

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

5 years, 5 months

1
0
0 0

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

by scan-admin＠coverity.com

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

5 years, 5 months

1
0
0 0

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

by Vivek Prasad

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

5 years, 5 months

3
3
0 0

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

by Joanna Farley

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

5 years, 6 months

1
0
0 0

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

by Soby Mathew

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

5 years, 6 months

3
6
0 0

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

by Sandrine Bailleux

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

5 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A