netdev - Re: [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm

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]

Date:   Thu, 6 Jan 2022 19:59:44 +0900
From:   Hector Martin <marcan@...can.st>
To:     Arend van Spriel <arend.vanspriel@...adcom.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-hsien Lin <chi-hsien.lin@...ineon.com>,
        Wright Feng <wright.feng@...ineon.com>,
        Dmitry Osipenko <digetx@...il.com>
Cc:     Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Mark Kettenis <kettenis@...nbsd.org>,
        Rafał Miłecki <zajec5@...il.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Hans de Goede <hdegoede@...hat.com>,
        "John W. Linville" <linville@...driver.com>,
        "brian m. carlson" <sandals@...stytoothpaste.net>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com
Subject: Re: [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob
 files

On 2022/01/06 19:19, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin wrote:
>> Teach brcm_alt_fw_paths to correctly split off variable length
>> extensions, and enable alt firmware lookups for the CLM blob firmware
>> requests.
>>
>> Apple platforms have per-board CLM blob files.
> 
> Are you sure? I am not involved in development for Apple platforms, but 
> in general we build a CLM blob specific for a chip revision. As always 
> with the blobs they are created at a certain point in time and that is 
> mostly why you need another one for a newer platform. Apple tends to do 
> things a bit different so you could be right though. Anyway, despite my 
> doubts on this it does not change the need for per-board firmware files.

Yup, I'm sure. The 2021 MacBook Pro 14" and the MacBook Pro 16", both
using BCM4387 and both released simultaneously, have different CLM
blobs; they're even a significantly different size. Running `strings` on
the files yields:

CLM DATA
Oly.Maldives
1.61.4
ClmImport: 1.63.1
v3 Final 210923

CLM DATA
Oly.Madagascar
1.61.4
ClmImport: 1.63.1
v4 Final 210923

The data shows significant differences and since the file format is
opaque I can't know what's going on. Even if it's safe to use one file
for both, unless there is some way for me to programmatically identify
this fact so I can incorporate that logic into my firmware copier, I
would much rather just keep them separate like Apple does.

> So all firmware files are attempted with board-specific path now.

Yes, I figured I'd keep things uniform. Technically for Apple platforms
the CLM blob and firmware are only per-board and possibly per-antenna
(they don't need the module variants, those are for nvram only), but
there's no real harm in unifying it and using the same firmware naming
alt path list for everything.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub