linux-kernel - Re: [PATCH v3] mhi: host: Add standard elf image download functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7nhlxp6gxk2tkuzh2rogywp6ko4n5nkh6ih2uly3zsskmi7wpp@7weahfg6gksm>
Date: Mon, 15 Dec 2025 20:41:32 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Qiang Yu <qiang.yu@....qualcomm.com>
Cc: Manivannan Sadhasivam <mani@...nel.org>, mhi@...ts.linux.dev,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mayank Rana <mayank.rana@....qualcomm.com>,
        Baochen Qiang <quic_bqiang@...cinc.com>
Subject: Re: [PATCH v3] mhi: host: Add standard elf image download
 functionality

On Sun, Dec 14, 2025 at 11:09:58PM -0800, Qiang Yu wrote:
> On Sat, Dec 13, 2025 at 11:21:11AM +0900, Manivannan Sadhasivam wrote:
> > On Fri, Dec 12, 2025 at 09:24:06PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Dec 12, 2025 at 10:07:01AM +0900, Manivannan Sadhasivam wrote:
> > > > On Thu, Dec 11, 2025 at 03:57:54PM +0200, Dmitry Baryshkov wrote:
> > > > > On Thu, Dec 11, 2025 at 01:37:12AM -0800, Qiang Yu wrote:
> > > > > > On Wed, Dec 10, 2025 at 12:57:11AM +0200, Dmitry Baryshkov wrote:
> > > > > > > On Sun, Dec 07, 2025 at 10:35:26PM -0800, Qiang Yu wrote:
> > > > > > > > On Sat, Dec 06, 2025 at 01:25:34PM +0200, Dmitry Baryshkov wrote:
> > > > > > > > > On Mon, Dec 01, 2025 at 06:33:15PM -0800, Qiang Yu wrote:
> > > > > > > > > > From: Mayank Rana <mayank.rana@....qualcomm.com>
> > > > > > > > > > 
> > > > > > > > > > Currently, the FBC image is a non-standard ELF file that contains a single
> > > > > > > > > > ELF header, followed by segments for SBL, and WLAN FW. However, TME-L
> > > > > > > > > > (Trust Management Engine Lite) supported devices (eg. QCC2072) requires
> > > > > > > > > > separate ELF headers for SBL and WLAN FW segments due to TME-L image
> > > > > > > > > > authentication requirement.
> > > > > > > > > > 
> > > > > > > > > > Current image format contains two sections in a single binary:
> > > > > > > > > > - First 512KB: ELF header + SBL segments
> > > > > > > > > > - Remaining: WLAN FW segments
> > > > > > > > > > 
> > > > > > > > > > The TME-L supported image format contains two sections with two elf
> > > > > > > > > > headers in a single binary:
> > > > > > > > > > - First 512KB: First ELF header + SBL segments
> > > > > > > > > > - Remaining: Second ELF header + WLAN FW segments
> > > > > > > > > > 
> > > > > > > > > > Download behavior:
> > > > > > > > > > - Legacy: 1. First 512KB via BHI (ELF header + SBL)
> > > > > > > > > >           2. Full image via BHIe
> > > > > > > > > > 
> > > > > > > > > > - TME-L: 1. First 512KB via BHI (First ELF header + SBL)
> > > > > > > > > >          2. Remaining via BHIe (Second ELF header + WLAN FW segments)
> > > > > > > > > > 
> > > > > > > > > > Add standard_elf_image flag to mhi_controller_config to indicate TME-L
> > > > > > > > > > supported image format. When set, MHI skips the first 512KB during WLAN FW
> > > > > > > > > > download over BHIe as it is loaded in BHI phase.
> > > > > > > > > 
> > > > > > > > > What is standard about it?
> > > > > > > > 
> > > > > > > > The TME-L requires standard elf image format which includes single EFL
> > > > > > > > header and WLAN FW segment.
> > > > > > > > 
> > > > > > > > The "standard_elf_image" seems misleading. Since the new image format is
> > > > > > > > required for TME-L image authentication, how about using 
> > > > > > > > tme_supported_image?
> > > > > > > 
> > > > > > > Just elf_image?
> > > > > > 
> > > > > > Is it too generic for this specific use case. Current image format also
> > > > > > contains elf header.
> > > > > 
> > > > > upload_elf_image?
> > > > > 
> > > > 
> > > > Nope. What does 'upload' even mean here? The 'TIS and ELF' spec v1.2 clearly
> > > > defines that an ELF executable can have only one ELF header. So I'd prefer
> > > > 'standard_elf_image' to differentiate it from the non-spec-conformant ELF image
> > > > used previously.
> > > 
> > > What kind of ELF image was used previously? Could you please explain
> > > what do 'First ELF header' vs 'Second ELF header' mean here?
> > > 
> > 
> > I don't have the details of it, but Qiang should be able to explain. But AFAIC,
> > that was a non-standard ELF image and the new one is going to be spec
> > conformant.
> >
> Previous image format:
> ELF header + SBL segments + WLAN FW segments
> 
> The TME-L supported image format:
> First ELF header + SBL segments + Second ELF header + WLAN FW segments

What is the Second ELF header in this context? ELF files usually have
only one header. Are we repeating the same ELF header or is some kind of
an embedded ELF-in-ELF.

> 
> As per 'TIS and ELF' spec v1.2 Mani mentioned, the previous image format

pointer?

> is also standard elf image. But it doesn't meet the requirement of TME-L
> because we need separate elf header for SBL and WL FW for TME-L
> authentication.
> 
> So the commit message stating "Currently, the FBC image is a non-standard
> ELF file that contains a single ELF header, followed by segments for SBL,
> and WLAN FW" is not correct and standard_elf_image is not accurate.
> 
> Can we avoid saying anything about standard in commit message? Flags eg.
> separate_elf_header and tme_supported_image are more accurate.

Please define, what is the supported image.

> 
> - Qiang Yu

-- 
With best wishes
Dmitry