[0/5] Add SPL support for Qualcomm platforms, starting with sdm845

[Michael Srba]

On 4/6/26 17:48, Simon Glass wrote:
> Hi Michael,
>
> On 2026-04-03T23:18:18, Michael Srba <michael.srba at seznam.cz> wrote:
>> U-Boot SPL, as it will be built using the defconfig added in this series,
>> replaces xbl_loader.
> Please can you clarify what happens on devices where XBL_SEC does not
> have this vulnerability? The code checks for EL3 and skips to reset,
> but if the SMC call to unlock secure regions fails, does the code
> handle this gracefully or crash?
The XBL_SEC ELF must be included as part of the u-boot ELF (this is what
the linker script does, yes it's cursed), so only a vulnerable one would
ever be included at build time (or if not, JTAG will be used to alter
the code flow).
Ideally a single fixed version would be included with u-boot as
an ambiguous bag of bytes that you are forced to put in your ELF to have
your actual code boot, but even if you could convince a judge that under
EU law that exempts you from copyright, under the US law you're presumably
screwed and in any case not getting sued is preferred.

In case the documentation is not clear enough on this, you absolutely
need to BYO an xbl_sec.elf (because I doubt u-boot wants to carry it,
and even if it does I'd rather not share "firmware" (using the definition
of "stuff that comes on your device and nobody ever wrote down a license
for, or just never gave it to you but that's actually not likely")).

For now unless you can find a vulnerable XBL_SEC you'll need to use
whatever you can get (e.g dumping one from existing xbl.elf on your device)
and use EUD or plain JTAG to jump to `start` from EL3.

I think it should be legal for an OEM to intentionally ship an old version
of XBL_SEC, but as for making it easily available for download that
depends on if Qualcomm distributes it to *them* with any sort
of license other than implicit  "obviously we won't sue you for using it
exactly the way we expect you to use it", and I kinda doubt they do.

To be absolutely clear, to my understanding there would be absolutely
no security detriments to qcom's precious (sadly legal) security model
if they just publicly released a stub xbl_sec that doesn't drop to EL1
before jumping to our code to linux-firmware, since the whole xbl.elf
is still signed by the OEM on the 99% of devices that put security over
freedom, but since they made the version of that which they did for google
explicitly check that it's running on an SoC fused from the factory
as intended-for-cros, I don't think they are going to do that.
Maybe it's a product segmentation thing, "how much extra can we charge
the few rare OEMs who don't want to use our super great stock bootloader".
(I don't think the idea of an end user having a say ever slips their mind)
> Regards,
> Simon