All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hector Martin <marcan@marcan.st>
To: Julian Calaby <julian.calaby@gmail.com>,
	Arend van Spriel <aspriel@gmail.com>
Cc: Franky Lin <franky.lin@broadcom.com>,
	Hante Meuleman <hante.meuleman@broadcom.com>,
	Kalle Valo <kvalo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Sven Peter <sven@svenpeter.dev>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Linus Walleij <linus.walleij@linaro.org>,
	asahi@lists.linux.dev, linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	SHA-cyfmac-dev-list@infineon.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device
Date: Tue, 14 Feb 2023 18:08:32 +0900	[thread overview]
Message-ID: <a9281140-8b9d-41ca-bc2d-3c2d2e78259e@marcan.st> (raw)
In-Reply-To: <CAGRGNgV6YMhBa1bdkf_EQ0Z+nwbfhJkKcTxtc=ukWVMWtvQ2PA@mail.gmail.com>

On 14/02/2023 18.00, Julian Calaby wrote:
> Hi Arend,
> 
> On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <marcan@marcan.st> wrote:
>>
>> Newer Apple firmwares on chipsets without a hardware RNG require the
>> host to provide a buffer of 256 random bytes to the device on
>> initialization. This buffer is present immediately before NVRAM,
>> suffixed by a footer containing a magic number and the buffer length.
>>
>> This won't affect chips/firmwares that do not use this feature, so do it
>> unconditionally for all Apple platforms (those with an Apple OTP).
> 
> Following on from the conversation a year ago, is there a way to
> detect chipsets that need these random bytes? While I'm sure Apple is
> doing their own special thing for special Apple reasons, it seems
> relatively sensible to omit a RNG on lower-cost chipsets, so would
> other chipsets need it?

I think we could include a list of chips known not to have the RNG (I
think it's only the ones shipped on T2 machines). The main issue is I
don't have access to those machines so it's hard for me to test exactly
which ones need it. IIRC Apple's driver unconditionally provides the
randomness. I could at least test the newer chips on AS platforms and
figure out if they need it to exclude them... but then again, all I can
do is test whether they work without the blob, but they might still want
it (and simply become less secure without it).

So I guess the answer is "maybe, I don't know, and it's kind of hard to
know for sure"... the joys of reverse engineering hardware without
vendor documentation.

If you mean whether other chips with non-apple firmware can use this, I
have no idea. That's probably something for Arend to answer. My gut
feeling is Apple added this as part of a hardening mechanism and
non-Apple firmware does not use it (and Broadcom then probably started
shipping chips with a hardware RNG and firmware that uses it directly
across all vendors), in which case the answer is no.

- Hector

  reply	other threads:[~2023-02-14  9:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14  8:00 [PATCH 0/2] Apple T2 platform support Hector Martin
2023-02-14  8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2023-02-14  9:04   ` Julian Calaby
2023-02-15 10:13   ` Linus Walleij
2023-02-27 10:41   ` [1/2] wifi: " Kalle Valo
2023-02-14  8:00 ` [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2023-02-14  9:00   ` Julian Calaby
2023-02-14  9:08     ` Hector Martin [this message]
2023-02-14  9:11       ` Julian Calaby
2023-02-23 15:01 ` [PATCH 0/2] Apple T2 platform support Aditya Garg
2023-02-23 15:04   ` Aditya Garg
     [not found]   ` <6588DEA1-673C-415E-A7AC-45CFBAA2B0F5@live.com>
2023-02-24  7:06     ` Aditya Garg
     [not found]   ` <BM1PR01MB09315D50C9380E9CB6471E9EB8A89@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM>
2023-02-24 13:11     ` Kalle Valo
2023-02-24 13:22       ` Aditya Garg

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=a9281140-8b9d-41ca-bc2d-3c2d2e78259e@marcan.st \
    --to=marcan@marcan.st \
    --cc=SHA-cyfmac-dev-list@infineon.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=aspriel@gmail.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=julian.calaby@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sven@svenpeter.dev \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.