> they aren't prohibiting operating systems, they _might_ be prohibiting installation of operating systems that are not approved on certain types of devices that ...
"prohibit installation" means to ban.
"operating systems that are not approved on certain types of devices that ..." means specific operating systems.
So, the FCC "might ban specific operating systems"; you've paraphrased what the title says.
I disagree - saying they might ban operating systems, with no context, leaves out the fact they're only talking about modular radio systems or software defined radio systems.
Edit: also to be clear, as another comment pointed out, this doesn't have any impact on test/kit equipment that is not compliant with FCC regulations anyway and requires a separate license to use - this is targeting consumer equipment. So I still think it's pretty misleading.
The rest is the fact that I think the article is wrong anyway :)
It's a title. Of course it's lacking context. If you want context, you read the rest of the essay, which explains everything you're doing much better than you are, and makes a solid case for why the FCC is, indeed, banning certain operating systems.
I still think it's kind of alarmist, but I can see your point of view as well. My goal was not to be better than their explanations, but only to summarize why I think they're being alarmist - I agree it's a topic worthy of discussion though :).
But the FCC regulates a great deal of equipment, and this is only targeting a very specific subset of that equipment - not all of it. I was initially pretty concerned as I'm a Ham radio operator, but this really does not concern me overly much now that it's clear it's:
Quite a bit of "consumer" equipment is halfway to an SDR already, and a ruling like this would mean you could never write or release FOSS firmware for a wireless card. (Note that wireless cards with FOSS firmware exist today.)
Yeah - it sucks and this FCC rules is concerning, but not as concerning as I initially thought it was.
Don't get me wrong - I think this is a stupid rule, but I just don't think it's as big a deal as the article, and title in particular, make it out to be.
Including the software that controls it. Which, in practice, includes the OS of a laptop or the firmware of a router, as discussed in the article. Technically that might not be the "entire device", but it's the part that matters.
> Which, in practice, includes the OS of a laptop or the firmware of a router, as discussed in the article.
The article is continuing to imply that the FCC is explicitly banning alt firmware for 5GHz WiFi devices. That is only the case if the module manufacturer fails to come up with any other way of getting their device approved. I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.
Given that this also means a brave new world of region-locked/region-specific 5GHz WiFi devices, and the added compliance burden for integrators ("host device manufacturers") trying to use modular transmitters that rely on host device manufacturer controls to achieve FCC approval, I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.
The situation where a modular transmitter places additional avoidable test/conformance/approval burden on the host device will also be a PITA for manufacturers, not just end-users.
> I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.
It's not an explicit goal. But the article argues (and I tend to agree) that the practical result will be manufacturers locking down their devices to prevent alt firmware from being loaded, since that will be the easiest and cheapest way for them to demonstrate compliance.
> I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.
Are you saying the manufacturers will come up with some way of locking down their radio firmware that still permits something like OpenWRT to be installed on a router (or Linux on a laptop, for that matter)? Why would they bother when they could just lock the device down completely?
> Are you saying the manufacturers will come up with some way of locking down their radio firmware that still permits something like OpenWRT to be installed on a router (or Linux on a laptop, for that matter)? Why would they bother when they could just lock the device down completely?
Yes. In the actual regs (which nobody seems to read), they suggest a list ("including but not limited to") a number of mechanisms by which manufacturers may choose to control the portion of their radio software that would impact the validity on their RF testing/validation/compliance results. One of them is signed firmware blobs: to me, that's the easiest, cheapest non-invasive method for WiFi module makers that won't create a huge compliance burden on the host device manufacturer. You go from having to load an unsigned firmware blob anyway, to a signed one. Which is a huge step in the right direction for firmware security anyway. As for modules which don't have blobs but do have the means to create non-compliant emissions just through the driver: it doesn't seem like much of a stretch that they could run new region-locked revs of their modules, or at least move those previously adjustable RF parameters/behaviours over to a signed image in a $0.10 SPI EEPROM chip.
All of this isn't just a PITA for users, it's a PITA for the device manufactures as well.
Particularly for laptop manufacturers. They could save $5 locking down the entire laptop, something they've never been able to do even when they try, or they could spend the extra $5 and get the module that's got a stand-alone certification and only requires them to submit a reference to the module's own FCC approval and some demonstration that the gain of the antennas in their product are in-spec.
I'm not sure I understand what you're describing here. Suppose I have a router and I want to run OpenWRT on it. Are you saying that the router will have basically two "firmwares" in it? One that controls the radio chip only, and is signed, and has some kind of defined driver interface; and another that controls the rest of the device, and has a driver that talks to the signed blob, so as long as OpenWRT has that driver, I'm good?
Or suppose I have a laptop and I want to load Linux on it. Are you saying the wifi chip inside the laptop will have a signed firmware blob that controls the radio, and has a Linux driver interface, so I can load Linux on the laptop and talk to the chip?
Assuming the above is correct, how different is it from the way these devices are designed now?
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.
> ...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.
Yes, that's a legitimate concern, but there's a small consolation that this is a problem only for existing SoC architectures doing 5GHz. The new regs don't rule out new SoC architectures which would implement the enforced separation in silicon somehow. Although you're still stuck not having access to modular transmitter rules but that was the case already.
> 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?
Indeed, although I have oversimplified somewhat - some basebands do run on the same CPU as the OS, but something resembling a secure hypervisor (with secured boot, among other things) is used to enforce isolation between the baseband and OS (see OKL4).
Are you being obtuse on purpose? The headline is intentionally worded in such a way to make people believe the FCC is going to ban OSX, Linux, or Windows.
If the author believes it's an important issue, he should be intellectually honest about it, because otherwise he risks having people write him off as a quack. It makes it look appear as if there aren't many valid arguments in his favor, so he has to resort to FUD.
"prohibit installation" means to ban.
"operating systems that are not approved on certain types of devices that ..." means specific operating systems.
So, the FCC "might ban specific operating systems"; you've paraphrased what the title says.