Message-ID: <0a028b79-01eb-b69f-79b2-c9588dd31ad1@marcan.st>
Date:   Mon, 27 Dec 2021 20:53:14 +0900
From:   Hector Martin <marcan@...can.st>
To:     Hans de Goede <hdegoede@...hat.com>, Lukas Wunner <lukas@...ner.de>
Cc:     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>,
        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>,
        "John W. Linville" <linville@...driver.com>,
        "brian m. carlson" <sandals@...stytoothpaste.net>,
        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: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms

On 2021/12/27 6:42, Hans de Goede wrote:
> Hi,
> 
> On 12/26/21 20:17, Lukas Wunner wrote:
>> On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote:
>>> # On firmware
>>>
>>> As you might expect, the firmware for these machines is not available
>>> under a redistributable license; however, every owner of one of these
>>> machines *is* implicitly licensed to posess the firmware, and the OS
>>> packages containing it are available under well-known URLs on Apple's
>>> CDN with no authentication.
>>
>> Apple's EFI firmware contains a full-fledged network stack for
>> downloading macOS images from osrecovery.apple.com.  I suspect
>> that it also contains wifi firmware.
>>
>> You may want to check if it's passed to the OS as an EFI property.
>> Using that would sidestep license issues.  There's EDID data,
>> Thunderbolt DROM data and whatnot in those properties, so I
>> wouldn't be surprised if it contained wifi stuff as well.
>>
>> Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties"
>> on the command line to see all EFI properties in dmesg.
>> Alternatively, check "ioreg -l" on macOS.  Generally, what's
>> available in the I/O registry should also be available on Linux
>> either as an ACPI or EFI property.
> 
> Interesting, note that even if the files are not available as
> a property we also have CONFIG_EFI_EMBEDDED_FIRMWARE, see:
> 
> drivers/firmware/efi/embedded-firmware.c
> Documentation/driver-api/firmware/fallback-mechanisms.rst
> 
> I wrote this to pry/dig out some touchscreen firmwares (where
> we have been unable to get permission to redistribute) out of
> EFI boot_services_code mem regions on tablets where
> the touchsceen is supported under the EFI environment.
> 
> This may need some tweaks, but if there is an embedded copy
> of the firmware files in the EFI mem regions somewhere it
> should be possible to adjust this code to grab it and present
> it to the firmware-loader mechanism as a fallback option.

Note that this wouldn't work on M1 Macs anyway, since those don't have
EFI (we provide EFI via U-Boot as a chained bootloader on those), and
their bootloader doesn't support any networking (it doesn't even do USB
or any kind of UI).

Quick recap for those not familiar with the M1 boot process: the
bootloader is iBoot, which is extremely simple (at least compared to
EFI). All it can do is boot kernels from APFS volumes on internal NVMe.
The boot selection menu and recovery options are implemented as macOS
apps running from a recovery image (~1GB), and "USB boot" is implemented
by copying the macOS equivalent of /boot to NVMe. There is a global
recovery image as well as per-OS recovery image. The WiFi firmware is
present in this image as well as on normal macOS root volumes.

Our Linux install script is actually mostly a macOS install script that
sets up all the boot components that macOS would normally have,
including the recovery image, minus the main root filesystem. This is
all required to work properly within Apple's security and multi-boot
framework. So, since we're installing the recovery image, we're already
in an easy position to pull the firmware out and stick it in the EFI
partition for Linux to easily use. The alternative would be for Linux
userspace to read it from APFS directly, but that seems unlikely to be
practical until linux-apfs is upstreamed.

For T2 Macs I'm sure the firmware will be in EFI somewhere, but even if
we can get it from there (I wouldn't be surprised if it's e.g. still
compressed in the normal boot path that doesn't start network services),
I'm not sure it's worth implementing yet another mechanism for those
machines. Once we have the vendor-firmware mechanism implemented for M1,
it's easy to just run the same script on T2s and get the proper firmware
from macOS (which might even be different from the EFI firmware...).
macOS definitely doesn't read the firmware from EFI on those machines,
so a hack to do it by scanning the code would probably not be something
we can rely on to continue working across firmware updates (and they do
update WiFi firmware; it's a rather well known source of security
issues... so then we'd have to play the update-the-sha256 cat and mouse
game). I'm pretty sure there's no property containing the big firmware
blob passed explicitly to the OS; it has its own copy.

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

Powered by blists - more mailing lists