So, well, we had this discussion already and I fail to see the point in doing such drastic things. It does not help anything or anyone except to keep the FSF endorsement for the OS. Everything else is just made worse by it. Hardware cost will rise, it is a significant development effort and in the end it does not create any benefit at all: The blob is still a blob and even worse, it gets taken out of the control of $average user since it is hidden in some hardware subsystem. This is neither helping to liberate anything nor does it help to make anything more secure. Quite the contrary is the case. You artificially limit users’ control over the firmware and you also limit the users’ (and OS for that matter) ability to apply additional security features to the firmware - like signing it with your own key or least creating your own checksums etc.
But all that aside, we have been talking about the firmware for the GPU here - or let’s take the WiFi firmware as another example. These are no simple SDIO devices, these are PCIe attached or even worse, in the case of the GPU, sit directly on the main CPU/SOC - either same silicon die or at least the same package. In the case of the GPU as part of the SOC I do not see a chance how an external additional microcontroller should be able to access that before the main SOC kicks in and takes ownership of the interface? But even for the WiFi card example, we are talking about PCIe here. So such a microcontroler would need to cut the PCIe pins from the main SOC, take control of the WiFi card’s PCIe interface as PCIe master, inject the firmware into the card and then let go of the interface and hand it back to the main SOC. This is not totally impossible, luckily there is PCIe hotplug. But this means to implement a pretty complex subsystem in hardware, a microcontroller that can talk PCIe etc. This is not something light weight you can do with some Arduino, we are talking about pretty serious SOCs here. And even if you would do that this would then end up in a system where only a limited number of WiFi card types can be supported since the controller then needs to store and match the card to a firmware in its storage, which again limits user’s freedoms in choosing hardware, they can not use any card they like, just the few that may or may not be supported.
And still all this does not address how firmware should get updated? If we accept these blobs in some form, be it also with painting them as “hardware”, it is no good idea at all to not considering updates. Even if we paint it as hardware it is still software and has bugs. Bugs that can also have severe security implications which often get addressed by firmware upgrades.
So in very short words: No, an external microcontroller can not be a solution.
Cheers
nicole