Arm Trusted Firmware-A BL1/BL2 boot stages on platforms that load firmware from a Firmware Image Package (FIP)

Impact

FIP headers are not signed, so BL1/BL2 parse attacker-influenceable metadata before authentication happens. Bad offsets and lengths make the loader read from secure memory mapped in the EL3 translation regime and land that data in non-secure memory. That is a pre-authentication leak of secure-world contents at boot - keys, secure heap, whatever is mapped. For a bare-metal provider this is a tenant-handoff problem: a tenant who can write the boot FIP (firmware update path, A/B slot, provisioning share) gets to exfiltrate secure-world state on the next boot for the next tenant.

Who can reach it

An attacker who can modify or supply the FIP image the platform boots from - anyone with the firmware-update path, a writable boot partition, or control of the provisioning pipeline. On bare-metal GPU rental that is the previous tenant if you do not verify firmware between handoffs.

What to do

Update TF-A past commits 48351 and 49485 (strict ToC bounds validation, overflow-safe arithmetic, short-read detection) and rebuild BL1/BL2 for the platform. That is an OEM-shipped firmware build, flashed to each node, reboot and drain. Independently: treat the FIP as tenant-writable until proven otherwise, and re-verify or re-flash boot firmware from a known-good image at every tenant handoff rather than relying on the parser being safe.

References