netdev - [RFC] MDIO firmware upload for offloading CPU

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-next>] [day] [month] [year] [list]

Message-ID: <27780925-4a60-f922-e1ed-e8e43a9cc8a2@aboehler.at>
Date:   Sun, 22 Mar 2020 14:56:40 +0100
From:   Andreas Böhler <news@...ehler.at>
To:     netdev@...r.kernel.org
Subject: [RFC] MDIO firmware upload for offloading CPU

Hi,

I'm working on support for AVM FRITZ!Box routers, specifically the 3390
and 3490. Both contain two SoCs: A Lantiq VDSL SoC that handles VDSL and
Ethernet connections and an Atheros SoC for WiFi. Only the Lantiq has
access to flash memory, the Atheros SoC requires firmware to be uploaded.

AVM has implemented a two-stage firmware upload: The stage 1 firmware is
transferred via MDIO (there is no PHY), the stage 2 firmware is uploaded
via Ethernet. I've got basic support up and running, but I'm unsure how
to proceed:

I implemented a user space utility that uses ioctls to upload the
firmware via MDIO. However, this only works when the switch
driver/ethernet driver is patched to allow MDIO writes to a fixed PHY
(actually, it now allows MDIO writes to an arbitrary address; I patched
the out-of-tree xrx200 driver for now). It is important to note that no
PHY probing must be done, as this confuses the target.

1. How should firmware uploads via MDIO be performed? Preferably in
userspace or in kernel space? Please keep in mind that the protocol is
entirely reverse-engineered.

2. If the firmware upload can/should be done in userspace, how do I best
get access to the MDIO bus?

3. What would be a suitable way to implement it?

Thanks,
Andreas