| FCC is talking about the radio firmware blobs which drive the radio MCU/DSP chip. That is where you have the capability to drive the device out-of-spec. Not (necessarily) the Linux environment it is being driven from. This is a discrete, separate part to the main ARM or x86 CPU running Linux (though some SoCs are blurring those lines). We already use firmware blobs on WiFi chips. It's why OpenWRT and friends are locked into old kernel versions for some routers: they don't have the source to the WiFi radio blob and can't recompile or reverse-engineer to make it work on newer kernels with different ABI. It's why we have a /lib/firmware directory for certain drivers in Linux: the device doesn't bother with flash memory, you have to load its firmware onto the device every power cycle into the DSP chip's memory. So for many devices currently in existence, separate radio firmware is already how things are architected. Some devices are flashed though, and don't require the host computer to load its own firmware, which is why I discussed a smaller EEPROM that would store signed config locking down the RF parameters and other aspects affecting certification. Basically separate radio and OS firmware are how mobile phones currently work. That's why you see separate baseband versions from your OS version info in "about this phone": these new rules for SDR devices (separate to U-NII discussion here) will actually require a whole new FCC approval for each radio firmware change. EDIT: And we haven't properly distinguished FCC approval process differences between modular WiFi transmitters (Eg. miniPCI-e cards) used in laptops and more expensive routers, which can self-contain and solve these issues by themselves without requiring the host device to care about U-NII security measures at all, versus cheaper/integrated products that may be crappy enough to require security measures in the main host device firmware in order to guarantee the radio firmware integrity to the FCC's satisfaction. |
> for many devices currently in existence, separate radio firmware is already how things are architected
This makes me feel better about things like laptops and routers (at least the more expensive ones), but this...
> cheaper/integrated products that may be crappy enough to require security measures in the main host device firmware in order to guarantee the radio firmware integrity to the FCC's satisfaction.
...makes me wonder about the future, since the trend for pretty much every category of device is towards "cheaper/integrated products". You mention that some SoCs blur the lines already.
> these new rules for SDR devices (separate to U-NII discussion here) will actually require a whole new FCC approval for each radio firmware change.
To make sure I understand, this would be an incentive for mobile phone manufacturers (for example) to continue to have separate radio firmware, even if they move to cheaper SoC designs, correct? Since otherwise (if there were only one firmware blob that contained both the OS and the radio controls), they would have to get FCC approval every time they wanted to push an OS update.