- TF-A - lists.trustedfirmware.org

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

4 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

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

4 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

4 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

4 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

4 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

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

4 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

4 years, 6 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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…

4 years, 6 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A