- TF-A - lists.trustedfirmware.org

by Soby Mathew

> > Subject: [PATCH] rpi3/4: Add support for offlining CPUs > From: Jan Kiszka <jan.kiszka(a)siemens.com> > > The hooks were populated but the power down left the CPU in limbo-land. > What we need to do - until there is a way to actually power off - is to > turn off the MMU and enter the spinning loop as if we were cold-booted. > This allows the on-call to pick up the CPU again. > > Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> > --- > plat/rpi/common/rpi3_pm.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/plat/rpi/common/rpi3_pm.c b/plat/rpi/common/rpi3_pm.c > index 8c2d070c4..2a6bf076b 100644 > --- a/plat/rpi/common/rpi3_pm.c > +++ b/plat/rpi/common/rpi3_pm.c > @@ -123,6 +123,15 @@ static void rpi3_pwr_domain_off(const psci_power_state_t *target_state) > #endif > } > > +void __dead2 plat_secondary_cold_boot_setup(void); > + > +static void __dead2 > +rpi3_pwr_domain_pwr_down_wfi(const psci_power_state_t *target_state) > +{ > + disable_mmu_el3(); > + plat_secondary_cold_boot_setup(); > +} > + > /******************************************************************************* > * Platform handler called when a power domain is about to be turned on. The > * mpidr determines the CPU to be turned on. > @@ -224,6 +233,7 @@ static void __dead2 rpi3_system_off(void) > static const plat_psci_ops_t plat_rpi3_psci_pm_ops = { > .cpu_standby = rpi3_cpu_standby, > .pwr_domain_off = rpi3_pwr_domain_off, > + .pwr_domain_pwr_down_wfi = rpi3_pwr_domain_pwr_down_wfi, > .pwr_domain_on = rpi3_pwr_domain_on, > .pwr_domain_on_finish = rpi3_pwr_domain_on_finish, > .system_off = rpi3_system_off, > -- > 2.16.4 > Hi Jan, I have put in a suggestion for the change. Basically, if you are able to do a `reset` before spinning in `plat_secondary_cold_boot_setup()`, that would be ideal. Also, if `plat_secondary_cold_boot_setup()` can trap the primary CPU as well if it were to be offlined, then I think your changes should be good. Best Regards Soby Mathew

6 years, 4 months

2
2
0 0

Re: [TF-A] About disable gic cpuif in psci suspend or off

by Soby Mathew

Hi Jisheng, This is due to the power management requirement of GICv3. In section 7.1 of GICv3 specification : https://static.docs.arm.com/ihi0069/c/IHI0069C_gic_architecture_specificati… It says the that " Before powering down the CPU interface and the PE when the Redistributor is powered up, software must put the interface between the CPU interface and the Redistributor into the quiescent state or the system will become UNPREDICTABLE". In order to put the Redistributor in a quiescent state, all the group enables in CPU interface must be disabled , otherwise "setting GICR_WAKER.ProcessorSleep to 1 when the physical group enables in the CPU interface are set to 1 results in UNPREDICTABLE behavior." Hope that clarifies. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Jisheng > Zhang via TF-A > Sent: 05 December 2019 10:31 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] About disable gic cpuif in psci suspend or off > > Hi, > > In ATF-A, I usually see below code in psci suspend or off code path: > > /* Prevent interrupts from spuriously waking up this cpu */ > plat_arm_gic_cpuif_disable(); > > But per my understanding, before calling psci_suspend(), the NW, e.g linux > kernel has disabled all interrupts from cpu level, so here preventing interrupt is > to prevent the interrupts from secure world? > > Another question is: for Cortex A55, this is not necessary. Because > CA55 TRM says when the core_pwrdn_en bit is set, executing WFI > automatically masks all interrupts and wake-up events in the core. Am I right? > > Thanks in advance > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 4 months

2
1
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Joanna Farley

Julius, On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. Joanna On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 5 months

2
1
0 0

Re: [TF-A] Design proposal: Property Access Layer

by Abhishek Pandit

Hi Louis, The term PAL is also used for platform abstraction layer so it "could" be confusing to have this being used for something different. Not necessarily suggesting to change anything but it might be worth considering this aspect. Thanks, Abhishek -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Louis Mayencourt via TF-A Sent: 19 November 2019 13:40 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Design proposal: Property Access Layer Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis 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

6 years, 5 months

2
2
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Sandrine Bailleux

Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine

6 years, 5 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi, Thanks George and Lionel for your answers. Following up and closing on this, the approach used in mentioned patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283) looks ok provided it should now build on all platforms. The original concern was about api breakage in the generic code, and that there might exist inconsistencies among platforms (ones depending on a 32b offset, others on 64 bits). Changing the generic seek api offset parameter from ssize_t to signed long long everywhere as a default makes it better compliant to using larger density storage chips in the long term. This is fine as long as it also still support older lower density chips. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 November 2019 18:34 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > 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

6 years, 5 months

1
0
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Andreas Färber

Hi S*deeps, Am 10.12.19 um 16:08 schrieb Sudeep Holla via TF-A: > The more we discuss, I think we will get to know all sorts of CENH(as you put) > are done all over the place and expecting system is work just fine even > when lots of interface/contracts are broken is just .....(fill your own word :)) > > I promise not to discuss these CENH any further after this email :) > > On Tue, Dec 10, 2019 at 03:59:01PM +0530, Sandeep Tripathy wrote: >> Hi Sudeep, >> >> On Mon, Dec 9, 2019 at 10:40 PM Sudeep Holla <sudeep.holla(a)arm.com> wrote: >>> >>> The application has to terminate cleanly when SIGTERM is sent(may be using >>> appropriate handler. And can intimate the same to the consumers so that they >>> can consume the data before it's lost. >> The DDR is not powered off ever in this scenario. So when to/how to consume >> the log is up to the (consumer) application design. > > CENH#1 > >> Assume its an incrementing log ie. after reboot this (producer) master again >> will continue to dump more records on to it. > > CENH#2 > > (I see the roles being exchanged, OS was slave + producer and not sure > what you are referring has master above. Anyways use KDUMP and features > like that if you need RAM dump for portions of memory given to the kernel. Sorry to barge in, but it sounds like you're not quite understanding each other in this ever-growing thread: Sandeep said his use case was a SmartNIC, so I assume the logging direction is from SoC on the SmartNIC to host SoC via PCIe? Think dmesg-like logs, from one host for another - I fail to see how Sudeep's kdump suggestion could help here. But maybe I'm not understanding properly, in which case I'll just blame your abstract master/slave discussions. :) To me and my ignorance however it sounds like this use case has nothing really to do with shutdown? If the log producer does not flush their logs after say each line ending, then also without shutdown you have no guarantee of the logs reaching the consumer in a timely manner through all the producer's caches, no? Think of watchdogs, power loss or other irregular resets that PSCI can do nothing about. Especially for logs, those error conditions would be the most important to receive data of. Cheers, Andreas >> How would you suggest to handle this. In this case both producer and >> consumer deliberately asked for coherent memory so why it should also >> consider a possible data loss due to platforms not giving the coherency >> because it will add some time to flush the core caches. > > CENH#3, not sure if such flexibility should be given to applications. > >> If they get non-cached(coherent) memory range they don't have to do anything >> isn't it ? > > Applications must not try that, kernel mostly provides cached memory from > it's memory allocator. I get a sense that this is some magic pre-allocated > memory that is either reserved or taken out of kernel memory, but the > application (along with its driver) maps it coherent in some magic way. > > -- > Regards, > Sudeep > -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

6 years, 5 months

3
2
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Andreas Färber

Hi Andre, Am 09.12.19 um 11:08 schrieb Andre Przywara via TF-A: > On Mon, 9 Dec 2019 08:41:47 +0100 > Jan Kiszka <jan.kiszka(a)web.de> wrote: >> How should we continue with the patch below? > > If you want to go into the lion's den that is gerrit, please feel free to submit this. Shouldn't be too hard for a single patch. Otherwise I need to look into some RPi4 TF-A stuff this week anyway, so could pick up your patch as well. [...] >> Subject: [PATCH] rpi3/4: Add support for offlining CPUs Seeing the "rpi3/4" here again: It's been some time since I pitched TF-A to the Foundation for RPi4 in vein, and my 2.1 based RPi3 test setup broke with some firmware update. Not seeing any message from Matthias here yet, are you aware that U-Boot has combined rpi3 and rpi4 targets into one? Are you looking into combining the PLAT=rpi{3,4} TF-A targets, too? We're targeting to use a single Linux image for both, so needing two different TF-A binaries would make TF-A adoption more difficult for us. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

6 years, 5 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Dan Handley

Hi Sandeep (I accidentally dropped the TF-A list in my last reply - now re-adding). > -----Original Message----- > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Sent: 05 December 2019 17:17 > > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that > > > it is managing an independent system or managing 'all' the masters > > > in a coherent domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. True, but TF-A tries to be a reference for all systems. > > 2. There is no observable difference between a graceful and non-graceful > > shutdown from the calling OS's point of view. The OS presumably has no > > knowledge of other masters it does not manage. > > Can CCN state machine go bad because one participating entity just goes off > without marking its exit ? > Please note I have not seen the issue and it is my assumption. > It depends on the interconnect. Arm interconnects designed for pre-v8.2 systems required explicit programming to take the master our of the coherency domain. Arm interconnects for v8.2+ systems do this automatically via hardware system coherency signals. The TF-A off/reset platform interfaces have provision to do this programming if necessary, but only for the running cluster, which is another reason not to use these PSCI functions in this scenario. > > 3. It's hard for firmware to implement in the multicore situation. > Agree. It is complex to initiate and ensure 'other cores' power down in > firmware. > > > > I haven't yet seen a reason why SYSTEM_SUSPEND won't work instead. > > > I think you are suggesting to use psci system suspend hook in reboot /power > off path Or use system suspend from the OS itself ? Should work. > I'm suggesting to just do a normal SYSTEM_SUSPEND (suspend to RAM) from the OS. > @Sudeep, I agree alternate approaches to solve data loss problem works and > may be those are the best suited. > The past thread[1] is somewhat related but diverged in multiple directions. > I wanted to know and focus the above 3 points especially point 2. Regards Dan. 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.

6 years, 5 months

3
14
0 0

RPi4 and CPU hotplugging

by Jan Kiszka

Hi Andre, I'm trying to get CPU offlining work for Linux on the RPi4. In fact, this is working already with current ATF master and the Raspberry kernel 4.19.85. Not it would be "nice" if onlining worked as well: [ 94.959294] CPU1: shutdown [ 94.959311] psci: CPU1 killed. [ 106.750960] CPU1: failed to come online [ 106.755425] CPU1: failed in unknown state : 0x0 Is this a known limitation? Or am I using the wrong kernel (obviously, it's a downstream one ;) )? Thanks, Jan PS: Current RPi firmware requires an explicit "armstub=armstub8.bin" in config.txt, no automatic pickup.

6 years, 5 months

3
6
0 0

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

by Sandrine Bailleux

Hi Sumit, Thanks for your answer. On 12/2/19 2:22 PM, Sumit Garg via TF-A wrote: > First of all, the authenticated encryption framework for FIP payloads > allows for algorithm parameter to be passed in the header (see struct > fip_toc_dec_data here [1]). So it should be easy to add support for > CCM algorithm too. > > Now coming on to additional reason to choose AES-GCM only (apart from > reasons that you have already mentioned) being: > - Currently mbedTLS only exposes partial decryption APIs for GCM > (mbedtls_gcm_starts(), mbedtls_gcm_update() and mbedtls_gcm_finish()) > but not CCM. And we need to rely on stack based partial decryption > approach (see gcm_decrypt() here [2]) as I think we can't afford large > buffers for both encrypted and plain firmware image. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/2/inclu… > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494/2/drive… I see, that makes sense to me. >> Also, I am still trying to get my head around how this would integrate >> with a cryptographic engine where the key does not leave the chip. I can >> imagine that we could get the address of the encrypted firmware image >> from the FIP, pass that to a cryptographic engine, request it to decrypt >> it and store the result somewhere in Trusted RAM. In this case, we >> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >> would pull this off? Like how the different modules (IO layer, crypto >> module, image parser module, ...) would integrate together? > > In this case, I would expect platform to provide key identifier rather > than actual key as part of plat_get_fip_encryption_key() which is then > passed onto auth_decrypt() that is implementation specific to > cryptographic engine in similar terms as currently done for mbedTLS > backend. Ah I see, so plat_get_fip_encryption_key() could return either the key itself or a key identifier. Just like plat_get_rotpk_info() can return either the key or a hash of it today. However, in the case of plat_get_rotpk_info(), it also returns some flags indicating which one it is. Don't we need something similar for plat_get_fip_encryption_key()? How will the crypto module be able to tell the difference between a key and a key ID otherwise? Or would you expect a given crypto module backend to always use either keys or key IDs, but not both? >> I have some concerns around the generation of the initialization vectors >> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >> would imagine that RAND_bytes() is typically based on a good random >> number generator and thus will generate different sequences every time >> it is called. At least, as long as it is called from the same machine >> every time. But what if we encrypt a new FIP bundle from a different >> machine, say in the context of a firmware update? Is it not possible >> that it might choose the same IV out of bad luck? >> >> Perhaps that's an issue left to provisioning/manufacturing time and is >> out of the scope here. But it worries me because AFAIU, the security of >> AES-GCM is critically undermined if the same nonce is used multiple >> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >> If the encryption key is the SSK (rather than the BSSK) then I guess the >> probability is even higher, as it is shared amongst a class of devices. >> > > Agree that "nonce" should be unique and using a random number > generator available on build machine was an effort towards that. But > thinking about the case that you have mentioned, I think we could have > an optional user provided "nonce" as an input to "encrypt_fw" tool, so > that the user is aware to randomly generate and provide a unique > nonce. Yes, I like your suggestion of specifying the nonce to the tool. But I think it should be the default behaviour then. You mention an *optional* user-provided nonce, I would like to suggest we make this mandatory instead. We could provide an option to request the tool to generate the nonce, intended for development purposes. >> Impact on memory footprint and performance >> ------------------------------------------ >> >> Do you know what the performance impact is when this feature is enabled >> in TF-A, to decrypt images at boot time? Obviously it depends on the >> platform and whether there is a dedicated cryptographic engine, and I >> suppose you cannot really get any relevant measurements out of QEMU but >> I would be interested if you've got any rough numbers. > > Following are measurements based on qemu for mbedTLS software library > based authenticated decryption: > > BL31 plain: > NOTICE: Load image time: 137us, size: 28KB > BL31 encrypted: > NOTICE: Load image time: 3979us, size: 28KB > > BL32 plain: > NOTICE: Load image time: 1791us, size: 360KB > BL32 encrypted: > NOTICE: Load image time: 36339us, size: 360KB Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have naively expected similar percentages, any idea why we get such a difference between BL31 and BL32? I am just curious. Maybe it's down to how the crypto algorithm/mode of operation works under the hood? > Following is the patch I used to take measurements in case someone is > interested to try it out on actual platform: > > diff --git a/common/bl_common.c b/common/bl_common.c > index e6f9802..d7303d2 100644 > --- a/common/bl_common.c > +++ b/common/bl_common.c > @@ -148,6 +148,7 @@ static int load_auth_image_internal(unsigned int image_id, > int is_parent_image) > { > int rc; > + unsigned long int ticks; > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > @@ -164,11 +165,16 @@ static int load_auth_image_internal(unsigned int image_id, > } > #endif /* TRUSTED_BOARD_BOOT */ > > + ticks = read_cntpct_el0(); > /* Load the image */ > rc = load_image(image_id, image_data); > if (rc != 0) { > return rc; > } > +#define SYS_COUNTER_FREQ_IN_TICKS ((1000 * 1000 * 1000) / 16) > + NOTICE("Load image time: %ldus, size: %dKB\n", > + (read_cntpct_el0() - ticks) * 1000000 / > SYS_COUNTER_FREQ_IN_TICKS, > + image_data->image_size / 1024); > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > >> >> And what's the memory footprint impact? IIUC, AES-GCM almost does not >> inflate the size of the data it encrypts. The size of the ciphertext >> seems to be the same as the plaintext + the size of the authentication >> tag. So I guess there's no real impact on flash storage and Trusted RAM >> usage to hold decrypted firmware. But what about the mbedTLS primitives >> to decrypt the images? How much code and data does this add? > > Following is my analysis on code and data increase due to mbedTLS primitives: > > Binary size: > ========= > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 58K Dec 2 12:53 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 66K Dec 2 12:53 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:53 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:53 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > After importing mbedTLS primitives to support AES-GCM algo: > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 67K Dec 2 12:56 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 78K Dec 2 12:56 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:56 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:56 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > Stack and heap: Works fine with default allocations on qemu. > ============ OK thanks. >> encrypt_fw tool >> --------------- >> >> We have some floating ideas around re-implementing the tools (fiptool, >> certtool) in a scripting language (possibly python) in the future and >> also doing a better job at sharing a common description of the list of >> images to boot/authenticate between the firmware and the host tools. But >> we're not there yet, so I agree that implementing this new tool in C >> from the same "mold" as fiptool and certtool is what makes the most >> sense today. It's just another tool we will have to rework if and when >> we get there. > > Sounds like a good idea to have these tools being python based. BTW, we noticed some copyright headers attributed to both Arm and Linaro and pre-dating year 2019, e.g. in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/3/tools… : * Copyright (c) 2015, ARM Limited and Contributors. All rights reserved. * Copyright (c) 2019, Linaro Limited I am guessing this is because this tool was derived from the existing cert_create tool code, is that right? >> I did not understand why this new tool needs to know what image it is >> encrypting. For example, one possible invocation could be: >> >> tools/encrypt_fw/encrypt_fw \ >> -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ >> --soc-fw bl31.bin \ >> --soc-fw-enc bl31_enc.bin \ >> --tos-fw bl32.bin \ >> --tos-fw-enc bl32_enc.bin >> >> Why not invoking the tool once per image instead? As in: >> >> encrypt_fw -k key -in ifile -out ofile >> >> for BL31, then for BL32? Does the tool do anything different based on >> the type of image it receives? > > "encrypt_fw" tool doesn't infer anything based on image type but image > types were added for more user visibility and ease of use as follows: > - Provides the capability to encrypt multiple firmwares on single invocation. I am not really convinced that this is a useful feature. I would rather have an external script (or the build system) invoking the tool multiple times, once per firmware image. Putting that complexity in the tool itself seems unnecessary to me. Also, it makes the tool TBBR specific, as it has to know the list of images it's allowed to encrypt. Unfortunately, we already have this TBBR knowledge embedded into the fiptool/cert_create tool today but we would like to change that in the future. It does not scale well with new images or alternative chains of trust. > - Restricts usage of tool for FIP payloads only. Why would we want that? > - Better align with Makefile framework to build command line args > while building different images and finally invoke tool at once before > creating FIP payload. Could we not invoke the tool for each image as we go along? As in, we build BL31 and just after we generate the encrypted version of it. Then we build BL32 and its encrypted version. And so on. While we do that, we build the fiptool command line that will indeed put all the encrypted images in the final FIP image. How does that sound? Regards, Sandrine

6 years, 5 months

2
1
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Thu, Dec 05, 2019 at 10:47:14PM +0530, Sandeep Tripathy wrote: > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > > Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that it is > > > managing an independent system or managing 'all' the masters in a coherent > > > domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. But we are talking about generic solution here, aren't we ? If so, it remains concern. [..] > I think you are suggesting to use psci system suspend hook in reboot > /power off path Or use system suspend from the OS itself ? Should work. > Just suspend, don't try to use PSCI SYSTEM_SUSPEND in reboot/poweroff path, not at-least in the generic code. If you think it works fine to address your issue, you can use it in your custom solution :) > @Sudeep, I agree alternate approaches to solve data loss problem works > and may be those are the best suited. No, the data loss issue had more open questions and I haven't understood the solution you have there. > The past thread[1] is somewhat related but diverged in multiple directions. OK, details again ? -- Regards, Sudeep

6 years, 5 months

1
0
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Sandrine Bailleux

Hi Julius, As you were mentioning that the Linux kernel uses /proc/sysrq-trigger for a similar purpose, I was wondering whether you'd be open to a solution based on a "DebugFS" entry. As you may have seen on the mailing list, Olivier posted a proposal for introducing a firmware debug interface, which has many similarities to how /proc or /sys works in the kernel world: https://lists.trustedfirmware.org/pipermail/tf-a/2019-October/000120.html TF-A patches for this feature are up for review right now and Olivier has also posted some TF-A Tests patches that demonstrate how this can be used from normal world. In addition, we are also working on a Linux driver for this. As you can imagine, DebugFS uses an SMC interface under the hood (currently allocated in the SiP range). But being an abstraction over the SMC layer, which specific SMC function ID is used does not matter so much and it does not need to be standardized by any Arm specification. You'd need to mandate all Chrome OS devices to have this DebugFS entry in the firmware but the backend could vary from platform to platform. Would that suit your use case? 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.

6 years, 5 months

2
1
0 0

Build config tool

by Balint Dobszay

Hi All, In TF-A we have a large set of build options (over 90). Dependency and incompatibility checks for these are currently done in the Makefile system. This can be hard to follow and difficult to maintain. We are investigating if there is a better way to describe the build options in a structured way, handle the dependencies/relations between them, and provide a more user-friendly configuration interface. A possible good solution for this is Kconfig, more specifically a Python implementation called Kconfiglib [1]. We plan to do more prototyping work in this area. Any feedback or comments on this topic are welcome. Regards, Balint [1] https://github.com/ulfalizer/Kconfiglib

6 years, 5 months

1
0
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Tue, Dec 3, 2019 at 4:58 PM Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > system shutdown or system reset PSCI calls are invoked by the last > core in the system. PSCI lib does not do cache flush for the last core > /cluster and does not follow the core / cluster power down sequence. > This may cause issue in a system if the system is not standalone one > ie if the system is a slave or node in a bigger system with other > coherent masters/PEs. > I am not sure if system off/reset is the right API to call in such a setup. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes and IIRC this has been discussed in the past[1]. I expect to get some closure on open question on that thread. Quite a few questions were raised by few people and I am not sure if all were answered. I need to dig but but AFAIK it wasn't all answered. -- Regards, Sudeep [1] https://lkml.org/lkml/2019/1/18/16

6 years, 5 months

2
2
0 0

About disable gic cpuif in psci suspend or off

by Jisheng Zhang

Hi, In ATF-A, I usually see below code in psci suspend or off code path: /* Prevent interrupts from spuriously waking up this cpu */ plat_arm_gic_cpuif_disable(); But per my understanding, before calling psci_suspend(), the NW, e.g linux kernel has disabled all interrupts from cpu level, so here preventing interrupt is to prevent the interrupts from secure world? Another question is: for Cortex A55, this is not necessary. Because CA55 TRM says when the core_pwrdn_en bit is set, executing WFI automatically masks all interrupts and wake-up events in the core. Am I right? Thanks in advance

6 years, 5 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hi Soby, Thanks for your response. >>it is needed to ensure the ordering of the succeeding sev(). Agree. Thanks for the clarification. >>Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code? Noticed it while reviewing code and I have not observed it on hardware. Thanks -Raghu On November 26, 2019 at 8:55 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew Thanks Raghu

6 years, 5 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Dan Handley

Hi Sandeep > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 03 December 2019 16:59 > > Hi, > system shutdown or system reset PSCI calls are invoked by the last core in > the system. That may be the case in practice but these functions can be called by any core in the system at any time, not just the last core. > PSCI lib does not do cache flush for the last core /cluster and > does not follow the core / cluster power down sequence. Correct. Not only that, it doesn't do anything with the other cores in the system that may be running at that time. > This may cause issue in a system if the system is not standalone one ie if > the system is a slave or node in a bigger system with other coherent > masters/PEs. > What issue specifically? Are the other coherent masters expecting to have the same view of the node's memory that the node had prior to calling system off/suspend? If so, then the node is not really independent to the wider system and system off/reset are probably not the right calls to use. Perhaps SYSTEM_SUSPEND is what you're looking for? That function requires all other cores to be off before the call and will perform cache maintenance on the last core. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes, the spec was deliberately relaxed between version 0.2 and 1.0 to allow implementations to just "pull the plug" since there would be no observable difference to the normal world caller between this behaviour and attempting to shutdown cleanly, which would be difficult and inherently racy anyway. > Otherwise in case it makes sense following is a patch to take care of this. > https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ > issue: https://developer.trustedfirmware.org/T566 Thanks but I don't think we want this. Regards Dan. 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.

6 years, 5 months

1
0
0 0

psci shutdown do not follow graceful power off sequence

by Sandeep Tripathy

Hi, system shutdown or system reset PSCI calls are invoked by the last core in the system. PSCI lib does not do cache flush for the last core /cluster and does not follow the core / cluster power down sequence. This may cause issue in a system if the system is not standalone one ie if the system is a slave or node in a bigger system with other coherent masters/PEs. Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to deliberately skip the core/cluster shutdown sequence. Otherwise in case it makes sense following is a patch to take care of this. https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ issue: https://developer.trustedfirmware.org/T566 Thanks Sandeep

6 years, 5 months

1
0
0 0

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

by Sandrine Bailleux

Hello Sumit, Sorry for not getting back to you earlier on this. I started looking at your patches and although I've not completely got my head around them yet, I've got some early comments and questions. I've tried to classify them by themes below. First of all, let me say that I'm no security expert and I did not know about the concept of authenticated encryption/decryption before looking at your patches. I spent a couple of hours reading about such algorithms in general and AES-GCM in particular. Most of what I've learned so far is based on my understanding of RFC 5116 [1]. What's the motivation for choosing GCM to start with? I've seen that it is free of patent [2], which I am guessing was a strong argument for it. I've also read that it is supposed to be quite lightweight and can take full advantage of parallel processing, although I've not looked into the details. Were these the reasons? Any other reasons? Key management -------------- fip_file_read() retrieves the key from the platform and stores it in a buffer on the stack. I don't see any code wiping it out of memory once we're done with it. Did I miss it? Unlike the root of trust public key, this is a (symmetric) secret key so it is sensitive data that we must not leave for grabs, even if the stack is in Trusted RAM and that it's likely to be overwritten by subsequent stack usage. Also, I am still trying to get my head around how this would integrate with a cryptographic engine where the key does not leave the chip. I can imagine that we could get the address of the encrypted firmware image from the FIP, pass that to a cryptographic engine, request it to decrypt it and store the result somewhere in Trusted RAM. In this case, we wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we would pull this off? Like how the different modules (IO layer, crypto module, image parser module, ...) would integrate together? I have some concerns around the generation of the initialization vectors in the encrypt_fw tool. Right now, IVs are simply a random sequence of bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I would imagine that RAND_bytes() is typically based on a good random number generator and thus will generate different sequences every time it is called. At least, as long as it is called from the same machine every time. But what if we encrypt a new FIP bundle from a different machine, say in the context of a firmware update? Is it not possible that it might choose the same IV out of bad luck? Perhaps that's an issue left to provisioning/manufacturing time and is out of the scope here. But it worries me because AFAIU, the security of AES-GCM is critically undermined if the same nonce is used multiple times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). If the encryption key is the SSK (rather than the BSSK) then I guess the probability is even higher, as it is shared amongst a class of devices. Impact on memory footprint and performance ------------------------------------------ Do you know what the performance impact is when this feature is enabled in TF-A, to decrypt images at boot time? Obviously it depends on the platform and whether there is a dedicated cryptographic engine, and I suppose you cannot really get any relevant measurements out of QEMU but I would be interested if you've got any rough numbers. And what's the memory footprint impact? IIUC, AES-GCM almost does not inflate the size of the data it encrypts. The size of the ciphertext seems to be the same as the plaintext + the size of the authentication tag. So I guess there's no real impact on flash storage and Trusted RAM usage to hold decrypted firmware. But what about the mbedTLS primitives to decrypt the images? How much code and data does this add? encrypt_fw tool --------------- We have some floating ideas around re-implementing the tools (fiptool, certtool) in a scripting language (possibly python) in the future and also doing a better job at sharing a common description of the list of images to boot/authenticate between the firmware and the host tools. But we're not there yet, so I agree that implementing this new tool in C from the same "mold" as fiptool and certtool is what makes the most sense today. It's just another tool we will have to rework if and when we get there. I did not understand why this new tool needs to know what image it is encrypting. For example, one possible invocation could be: tools/encrypt_fw/encrypt_fw \ -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ --soc-fw bl31.bin \ --soc-fw-enc bl31_enc.bin \ --tos-fw bl32.bin \ --tos-fw-enc bl32_enc.bin Why not invoking the tool once per image instead? As in: encrypt_fw -k key -in ifile -out ofile for BL31, then for BL32? Does the tool do anything different based on the type of image it receives? Regards, Sandrine [1] https://tools.ietf.org/html/rfc5116 [2] https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents…

6 years, 5 months

2
1
0 0

Design proposal: new buildsystem

by Balint Dobszay

Hi All, The buildsystem of TF-A became complex and loaded with technical debt during the years, and it's time to do something about this. We made some plans and prototyping work to move to a CMake based solution and we would like to get feedback on the idea. Why CMake? In summary CMake is a mature tool having a wide acceptance in C and C++ projects. Also it has benefits of decreasing fragmentation in the developer community if we sync up with TF-M. How will it happen? This will be a slow process where the old build system will co-exist for a period with the new one. How long that period will be is an open question. For a more detailed summary please see https://developer.trustedfirmware.org/w/tf_a/cmake-buildsystem-proposal/ The design discussion will follow the design review proposal process of TF.org, as described on this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… You can find the patch for capturing the design decisions and discussion here: https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2662/ If you would like to contribute or have an opinion or any ideas please reply to this email or add a comment on Gerrit (link above). Regards, Balint 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.

6 years, 5 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Soby Mathew

On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: > Hello! > > Reposting this from (https://developer.trustedfirmware.org/T589). > > bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? > Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. > If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew > Thanks > Raghu >

6 years, 5 months

1
0
0 0

Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. Thanks Raghu

6 years, 5 months

1
0
0 0

Review hiccups

by Julius Werner

Hi Soby (and others), We've had a couple of MT8183 platform patches on Gerrit waiting for review/merge for a while (one over a week). Could you please help make sure they are in someone's queue at Arm? https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2379 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2175 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2401 (need kick off CI) Let me know if there's anything else we can do to help increase turnaround time on Gerrit. Thanks, Julius

6 years, 5 months

2
1
0 0

How to verify image BL1

by Iñigo Vicente Waliño

Hi, I am using QEMu to simulate the ARMv8 platform. How can I verify that the BL1 image is in the ROM? And if not, can I not find it? Thanks, Iñigo.

6 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A