linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hector Martin <marcan@marcan.st>
To: Hans de Goede <hdegoede@redhat.com>, Lukas Wunner <lukas@wunner.de>
Cc: Kalle Valo <kvalo@codeaurora.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Arend van Spriel <aspriel@gmail.com>,
	Franky Lin <franky.lin@broadcom.com>,
	Hante Meuleman <hante.meuleman@broadcom.com>,
	Chi-hsien Lin <chi-hsien.lin@infineon.com>,
	Wright Feng <wright.feng@infineon.com>,
	Sven Peter <sven@svenpeter.dev>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Mark Kettenis <kettenis@openbsd.org>,
	Rafa?? Mi??ecki <zajec5@gmail.com>,
	Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com,
	SHA-cyfmac-dev-list@infineon.com
Subject: Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms
Date: Mon, 27 Dec 2021 20:53:14 +0900	[thread overview]
Message-ID: <0a028b79-01eb-b69f-79b2-c9588dd31ad1@marcan.st> (raw)
In-Reply-To: <06e801a0-7580-48ed-cac2-227c32a74ec2@redhat.com>

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@marcan.st)
Public Key: https://mrcn.st/pub

  reply	other threads:[~2021-12-27 11:53 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-26 15:35 Hector Martin
2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
2021-12-26 21:02   ` Linus Walleij
2021-12-26 23:34   ` Rob Herring
2021-12-27 16:36   ` Rob Herring
2021-12-27 17:23     ` Hector Martin
2021-12-29 16:38       ` Mark Kettenis
2022-01-02 14:12         ` Hector Martin
2021-12-29 16:42   ` Mark Kettenis
2022-01-04  5:47     ` Hector Martin
2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
2021-12-26 21:04   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
2022-01-02  5:31   ` Linus Walleij
2022-01-02  7:10     ` Dmitry Osipenko
2022-01-02  6:38   ` Dmitry Osipenko
2022-01-02  6:45   ` Dmitry Osipenko
2022-01-02 14:18     ` Hector Martin
2022-01-02 20:11       ` Dmitry Osipenko
2022-01-03  0:41         ` Hector Martin
2022-01-03  1:26           ` Dmitry Osipenko
2022-01-03  6:17             ` Hector Martin
2022-01-02  6:55   ` Dmitry Osipenko
2022-01-03  6:18     ` Hector Martin
2022-01-02  7:08   ` Dmitry Osipenko
2022-01-02  7:20     ` Dmitry Osipenko
2022-01-02 14:25     ` Hector Martin
2022-01-02 20:12       ` Dmitry Osipenko
2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
2022-01-02  6:21   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
2022-01-02  6:22   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
2022-01-02  5:34   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
2022-01-02  5:38   ` Linus Walleij
2022-01-03  5:51     ` Hector Martin
2022-01-03 11:13       ` Linus Walleij
2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
2022-01-02  5:40   ` Linus Walleij
2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
2022-01-02  5:44   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
2022-01-02  5:50   ` Linus Walleij
2022-01-03  5:42     ` Hector Martin
2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
2022-01-02  5:50   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
2022-01-02  5:51   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
2022-01-02  5:53   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
2022-01-02  5:53   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
2021-12-26 18:20   ` Lukas Wunner
2022-01-02  6:20   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2022-01-02  5:58   ` Linus Walleij
2022-01-03  6:03     ` Hector Martin
2022-01-03 11:14       ` Linus Walleij
     [not found]   ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
2022-01-03 17:22     ` Hector Martin
     [not found]       ` <CAHp75Vedgs_zTH2O120jtUuQiuseA0VN62TJiJ7kAi1f5nDQ6Q@mail.gmail.com>
2022-01-04  5:22         ` Hector Martin
2022-01-10  9:59     ` Kalle Valo
2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2022-01-02  5:59   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
2022-01-02  6:00   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
2022-01-02  6:01   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
2022-01-02  6:02   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
2022-01-02  6:03   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
2022-01-02  6:09   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
2022-01-02  6:23   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
2022-01-02  6:11   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
2022-01-02  6:12   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
2022-01-02  6:13   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
2022-01-02  6:13   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
2022-01-02  6:15   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
2022-01-02  6:16   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
2022-01-02  6:16   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
2022-01-02  6:17   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
2022-01-02  6:18   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
2022-01-02  6:19   ` Linus Walleij
2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
2022-01-02  6:19   ` Linus Walleij
2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
2021-12-26 21:42   ` Hans de Goede
2021-12-27 11:53     ` Hector Martin [this message]
2022-01-02  6:25 ` Linus Walleij
2022-01-03  6:27   ` Hector Martin
2022-01-03 10:20     ` Arend van Spriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a028b79-01eb-b69f-79b2-c9588dd31ad1@marcan.st \
    --to=marcan@marcan.st \
    --cc=SHA-cyfmac-dev-list@infineon.com \
    --cc=alyssa@rosenzweig.io \
    --cc=aspriel@gmail.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=chi-hsien.lin@infineon.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=hdegoede@redhat.com \
    --cc=kettenis@openbsd.org \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=lukas@wunner.de \
    --cc=netdev@vger.kernel.org \
    --cc=pieter-paul.giesberts@broadcom.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=sven@svenpeter.dev \
    --cc=wright.feng@infineon.com \
    --cc=zajec5@gmail.com \
    --subject='Re: [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).