Hi Marek, On Wed, Mar 11, 2026 at 04:42:54PM +0100, Marek Vasut wrote: > On 3/10/26 12:54 PM, Simona Toaca (OSS) wrote: > > From: Simona Toaca <[email protected]> > > > > This patch series adds support for saving DDR training > > data to non-volatile memory on iMX94 and iMX95 platforms. > > The purpose is running DDR Quickboot flow on next reboot. > > > > The process is as follows: > > - OEI runs Training flow for the DDRPHY > > - OEI saves the data from training to volatile memory > > - U-Boot can then save it to non-volatile memory (e.g. SD) > > - OEI loads the data from NVM at cold reboot and runs Quickboot flow > > > > By skipping training, a much lower boot time is achieved. > How does this interact with authenticated boot ? I wonder if, in case the > entire bootloader stack is authenticated, the attacker can tamper with the > saved QB data (which do not seem to be authenticated) and cause bitflips to > occur in DRAM, which could then allow them to bypass authentication in > follow up stages which execute from DRAM ? > > Are the QB data protected/authenticated in any way against tampering ?
In U-Boot there is no authentication for qb, it's just the CRC that is used to ensure the qb data was not overwritten by another (non-malicious) entity. OEI is the first boot component that runs during the bootflow and is in charge of verifying if the data stored in NVM is valid or not. With the exception of iMX95 A0/A1, which use a CRC as well for this purpose, the other boards (iMX95 B0, iMX943, etc.) use ELE to verify a MAC stored in the qb_state structure. This provides the authentication part. If someone tampers with the data and it somehow gets saved to NVM, the worst case scenario is that Training flow will run instead of the Quickboot flow. I am not sure that it can have any other impact. Especially in the case where SPL saves qb data, the DRAM address can then be used for image loading without worrying about qb or what data had been written there. Kind regards, Simona
