Wireless regulatory compliance [LWN.net]

Wireless networking vendors have, over time, developed a large and imaginative set of reasons for their refusal to make free drivers and hardware programming information for their products available. One of those reasons is regulatory compliance; if untrusted parties can modify a wireless device driver, they may (accidentally or not) program the device to operate outside of the rules governing frequency use and power levels in their specific area. Some vendors apparently believe that they could be held responsible for what others do with their hardware, especially in parts of the world with relatively aggressive enforcement of regulations on spectrum use. While the United States is often mentioned in such discussions, people who have studied the issue tend to worry more about Japan. That said, there are regulations worldwide - differing regulations - and a Linux system with radio transmitters in it will be expected to comply with those regulations.

To that end, Larry Finger has recently returned with a new version of his proposal for a mechanism which would enable Linux to operate wireless adapters in a legally-sanctioned way. The scheme involves the creation of a database describing the regulatory regime in various parts of the world. At system startup, a user-space daemon would determine (somehow) where the system was located, obtain the relevant parameters from the database, and feed them into the mac80211 subsystem, which would then instruct drivers on how to program their devices. In the absence of instructions from user space, the kernel would fall back to a minimal configuration known to be legal worldwide - if such a configuration can be found.

There was some interesting feedback, starting with the assertion that the mac80211 layer is the wrong place for a regulatory module. There are wireless adapters which have full MAC capability built into them, and which will not use mac80211, but these devices have the same regulatory issues. Beyond that, Linux systems can contain other sorts of transmitters, starting with BlueTooth adapters and going on from there. If this sort of regulatory compliance is to be added to the kernel (and cleaned out of various drivers where it already exists), it would be best to add it once and have it work in all situations. It turns out that some thought has gone into a kernel "frequency broker" module which would handle this task, but development has not yet gone very far.

Overly zealous regulatory enforcement is a concern for some users. There are people running Linux who have licenses allowing spectrum use which is denied to most of us. They would, understandably, like to be able to use their hardware (when it is capable of such use) in ways which take advantage of their wider permissions. If the kernel eventually adopts a regulatory mechanism which cannot be overruled, it will prevent some users from doing things which they are legally entitled to do. Until they go into the code and disable the regulatory code, at least.

Of course, if legal users can override the regulatory mechanism, others can as well. That leads to the question of whether a regulatory regime implemented in free software can ever be good enough to satisfy the authorities. Luis Rodriguez pointed out an April, 2007 ruling [PDF] from the U.S. Federal Communications Commission which suggests that there could be trouble there:

The Commission did not address the possibility of manufacturers using open source software to implement security measures. However, we recognize that hardware and software security measures that interact with the open source software need not be subject to an open source agreement. We are hereby stating that it is our policy, consistent with the intent of Cognitive Radio Report and Order and Cisco's request, that manufacturers should not intentionally make the distinctive elements that implement that manufacturer's particular security measures in a software defined radio public, if doing so would increase the risk that these security measures could be defeated or otherwise circumvented to allow operation of the radio in a manner that violates the Commission's rules. A system that is wholly dependent on open source elements will have a high burden to demonstrate that it is sufficiently secure to warrant authorization as a software defined radio.

(Emphasis added).

If free regulatory code will never be good enough for regulatory agencies, one might well ask whether it is worth the trouble for Linux developers to implement such a module in the first place. One could answer that operating transmitters in a way consistent with their licensing is the correct thing to do, regardless of whether governments see it as being sufficiently robust. But, if the main concern is keeping governments happy, the only real solution may be to do as Intel has done and move regulatory compliance back into the device's firmware and away from the host operating system altogether. This approach brings an additional benefit in the form of eliminating one excuse for not releasing free drivers.

(Log in to post comments)

Wireless regulatory compliance

Posted Jun 7, 2007 12:59 UTC (Thu) by timschmidt (guest, #38269) [Link]

To further your point, I hereby formally suggest that all _hardware_ radios implement such databases and self-diagnostics as necessary to prevent an electronics enthusiast from modifying said radio to operate outside of compliance with FCC mandates.

Wireless regulatory compliance

Posted Jun 7, 2007 15:45 UTC (Thu) by sepreece (subscriber, #19270) [Link]

My understanding was that the FCC does consider this in type certifying devices for manufacture and that it has also acted to restrict importation of devices that were too easy to modify.

Wireless regulatory compliance

Posted Jun 7, 2007 17:07 UTC (Thu) by timschmidt (guest, #38269) [Link]

Define 'too easy to modify'. You can't. Anything can be too easy to modify - to the right person. Kernel space may seem simple to you, but to the other 99.999%, it's every bit as cryptic (more so!) than some electronic gadget they can hold in their hands.

Wireless regulatory compliance - "too easy to modify"

Posted Jun 8, 2007 16:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

You missed his point. The FCC does define it. I don't know the definition, but I'm sure it exists in copious written words, and there are copious examples of devices that do and do not meet the definition. It's real, which means prohibiting open source software radios can be too.

Law is positively full of things that cannot be crisply defined and yet are defined.

In the US, when you borrow something and it gets damaged because you failed to use "great care" in handling it, you have to pay for the damage. Can you define "great care"? The law does -- in hundreds of thousands of words, which form a definition that is actually clear enough that in the vast majority of cases, a borrower and lender don't even need a judge to determine whether a borrower used great care or not.

If there can be a useful definition of something so nebulous as great care, I'm sure there can be a useful definition of "too easy to modify."

Who is missing the point?

Posted Jun 8, 2007 21:55 UTC (Fri) by GreyWizard (guest, #1026) [Link]

Both you and sepreece are missing the point. Consider the first sentence of the first comment on this thread: "It seems completely insane to me to insist that software MUST prevent (or atleast take steps to prevent) the user of said software from breaking the law wherever he may be at the moment." This thread is about what the rules SHOULD be and not what they ARE.

Regulations that hold manufacturers accountable for the actions of customers who recompile kernels or apply a soldering iron might exist but they don't serve society well. We should find ways to talk sense into those who perpetuate bad ideas rather than ending the discussion with "that's just how it is."

Who is missing the point?

Posted Jun 8, 2007 22:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

There are plenty of points to miss here, but the point to which I was referring was a point made by Sepreece, which I think I did catch, and of course he could not have missed himself.

And Sepreece was only rebutting a specific argument made by Timschmidt, not the general idea of whether limitations on radio software are good for society. Neither of us has voiced a position on that.

Timschmidt made the obviously satirical suggestion that hardware radios contain measures to prevent people from modifying them. I take this to mean, "having to make software hard to modify is as ridiculous as having to make hardware hard to modify, which is obviously so ridiculous noone would do it." So the inconsistent fact that the government does in fact do it is right on point.

All well and good, but...

Posted Jun 9, 2007 20:14 UTC (Sat) by GreyWizard (guest, #1026) [Link]

Yes, I noticed all that and I didn't intend to accuse you of putting forward a non sequitur. I don't dispute the factual basis of your comment but rather the implication that this is all that matters (this appears to me intentional since you chose not to comment on the merits of the regulation). Requiring that hardware be hard to intentionally modify is indeed ridiculous, even if government is daft enough to do so.

Who is missing the point?

Posted Aug 3, 2007 1:40 UTC (Fri) by timschmidt (guest, #38269) [Link]

"Timschmidt made the obviously satirical suggestion that hardware radios contain measures to prevent people from modifying them. I take this to mean, "having to make software hard to modify is as ridiculous as having to make hardware hard to modify, which is obviously so ridiculous noone would do it." So the inconsistent fact that the government does in fact do it is right on point."

OK. Name a few radios with FCC-mandated hardware anti-hacking measures.

Wireless regulatory compliance

Posted Jun 7, 2007 13:02 UTC (Thu) by rvfh (subscriber, #31018) [Link]

I think you will soon-ish have cars using GPS and maps to restrict your
speed. But more to the point, even proprietary drivers do not prevent
illegal use. The user still has to say which country she's in to see some
channels disappear from her WiFi settings. Some countries do not allow
802.11a, but you can use anyway if you pretend to be in a country that
does.

So yes, I agree with you, the user is responsible, not the tool.

Wireless regulatory compliance

Posted Jun 7, 2007 16:37 UTC (Thu) by danm628 (subscriber, #5995) [Link]

Actually modern WiFi devices get their regulatory domain from the access point they are connected to. So long as the AP is configured for the correct country then all of the devices that are near enough to receive it's beacons will comply with the correct regulatory domain. Most APs do not allow you to set the regulatory domain, they come pre-configured for the country they are being sold in. (There are exceptions to this, high end APs often allow setting the regulatory domain and a few cheaps one do also.)

802.11a is a bit harder, the frequency spectrum is fragmented and in addition to the regulatory domain issues you have to deal with RADAR avoidance. The 802.11a device is required to listen for signals that look like RADAR, if it detects one it must signal the AP that it found one and then the AP and everything connected to it will change frequencies. This is relatively easy to do for civil RADAR systems, the headache comes with military RADAR. The signal format is usually classified so you don't know what it is that you are supposed to be avoiding. (I hated dealing with this when I used to work on WiFi -- it was worse than the regulatory domain stuff.)

The other problem with putting the regulatory information into Linux is keeping it current. Laws change. Spectrum that is legal today may become illegal next year. Or suddenly become legal.

Wireless regulatory compliance

Posted Jun 7, 2007 20:26 UTC (Thu) by khim (subscriber, #9252) [Link]

I've not seen AP without this ability. Cheap or expensive: if you have access to configuration - you can choose the country. Big number of providers lock access to the configuration, though...

Wireless regulatory compliance

Posted Jun 7, 2007 14:59 UTC (Thu) by a9db0 (subscriber, #2181) [Link]

>> The user is responsible for not using tools in illegal ways. Not the tool. <<

Absolutely.

And there is a fairly compelling argument to be made that incorporating such a mechanism into the kernel indicates a willingness of the kernel maintainers to accept responsibility for such use, and possibly misuse.

I can see some lawyer making the argument that since the mechanism exists that his client isn't responsible for any misuse - such responsibility lies with the developer. And woe to the developer who finds himself in hot water with the regulatory agencies of some locality because some user misused code he wrote.

Wireless regulatory compliance

Posted Jun 7, 2007 23:17 UTC (Thu) by socket (guest, #43) [Link]

I think your argument conflates two issues: mechanisms/processes, and data. The kernel could provide a mechanism for userspace to tell it about valid frequencies/power levels the system can transmit on, and a means for enforcing those specifications.

In the boot-up process, something can tell the kernel about those specifications. The kernel really has to take userspace's word for it that the specifications loaded actually match the legal regulations for the user.

You're trying to say that the developer of a mechanism is responsible for every individual's use of that mechanism. If I tell the kernel that I have the right to transmit within the less restrictive rules granted by an amateur radio license (when in fact I don't have said license), what logic allows you to blame the kernel developer?

And if that logic is accepted, consider this: if someone gains root access on a system through a local privilege escalation issue, why shouldn't the kernel developers be held responsible for it on the basis that the implementation of privilege separation by user id is implemented in the kernel? Even if the cause of the problem was clearly based on the wrong user owning the file in question?

If the kernel developers have to accept responsibility for the legitimacy of the *data* that informs the rules of a more generic system, like file permissions or acceptable frequencies to transmit on, then how could anybody *other* than the kernel developers be responsible for *any* system (or spectrum usage) integrity issue? Clearly, this is nuts.

In the abstract, the process of deciding whether access is allowed needs to be provided information somehow (whether by a user or designer) about how to make that decision. The FCC seems to believe it should always be the designer, we mostly feel this causes more problems than it solves.

Blaming the access restriction mechanism for the validity of the data it's given to make its decisions presumes omnipotence on the part of the creators of that access restriction mechanism. Designers *can't* predict every use, and shouldn't be expected to. Kernel developers can't rightfully take the blame for my failures to choose the right permissions for my files, so neither should they take the blame for users specifying incorrect spectrum use rules.

And if the FCC can't understand this, they need some clue.

Wireless regulatory compliance

Posted Jun 8, 2007 1:48 UTC (Fri) by bronson (subscriber, #4806) [Link]

I suspect the GP was talking about bugs... If a developer accidentally writes code that allows illegal use, then is the developer negligent? Can the developer prove that exhaustive testing was performed? Are unit tests admissible in a court of law? :)

Wireless regulatory compliance

Posted Jun 8, 2007 15:52 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

And proprietary code has no bugs?

Wireless regulatory compliance

Posted Jun 8, 2007 18:43 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Code that has gone through certification testing and is thereafter largely immutable may not be bug free, but it's certainly close enough. The problem is that free and open software is explicitly mutable.

Wireless regulatory compliance

Posted Jun 8, 2007 17:09 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

It seems completely insane to me to insist that software MUST prevent (or atleast take steps to prevent) the user of said software from breaking the law wherever he may be at the moment.

It might be suboptimal, but it's definitely not insane. The question of at what point in the chain of behavior you should stop antisocial things from happening is omnipresent in law, and much of the time -- most, in fact -- we as a society opt to put responsibility somewhere other than the final link in the chain. Even though it effectively outlaws some additional things that aren't antisocial at all.

Some popular examples of the controversy: do you stop murders by making it against the law to manufacture guns? Own guns? Or just to shoot people? Do you make it against the law to take a weapon into an airport, or just to hijack a plane? In the techology world: should it be against the law to sell a cable descrambler, or just to watch TV with it?

We like to move up the chain because it's more efficient. Would you rather pay $1000 in taxes to have the government track down broadcasters or $10 to track down radio manufacturers?

Typical cars will, infact, if you push the pedal to the metal, go faster than the speed-limit at your location.

There's a good counterexample here, too. Some cars have legally required "governors" on them to prevent them from going above a certain speed. Sane people in those jurisdictions have decided it's the best tradeoff to stop speeding.