Regulating wireless devices

Whenever a Linux system communicates with the rest of the world, it must follow a whole set of rules on how that communication is done. Basic TCP/IP networking would work poorly indeed in the lack of an observed agreement on how the networking medium should be used. Wireless networking has all of those constraints, plus a set of its own. Since wireless interfaces are radios, they must conform to rules on the frequencies they can use, how much power they may emit, and so on. If all goes well, Linux will finally have a centralized mechanism for ensuring that wireless devices are operated according to that wider set of rules.

Regulations on radio transmissions bring some extra challenges. They are legal code, so their violation can bring users, vendors, and distributors into unwanted conversations with representatives of spectrum enforcement agencies. The legal code is inherently local, while wireless devices are inherently mobile, so those devices must be able to modify their behavior to match different sets of rules at different times. And some wireless devices can be programmed in quite flexible ways; they can be operated far outside of their allowed parameters. The possibility that one of these devices could be configured - accidentally or intentionally - in a way which interferes with other uses of the spectrum is very real.

The potential for legal problems associated with wireless interfaces has cast a shadow over Linux for a while. Some vendors have used it as an excuse for their failure to provide free drivers. Others (Intel, for example), have reworked their hardware to lock up regulatory compliance safely within the firmware. And still, vendors and Linux distributors have worried about what kind of sanctions might come down if Linux systems are seen to be operating in violation of the law somewhere on the planet. Despite all that, the Linux kernel has no central mechanism for ensuring regulatory compliance; it is up to individual drivers to make sure that their hardware does not break the rules. This situation may be about to change, though, as the Central Regulatory Domain Agent (CRDA) patch set, currently being developed by Luis Rodriguez, approaches readiness.

At the core of CRDA is struct ieee80211_regdomain, which describes the rules associated with a given legal regime. It is a somewhat complicated structure, but its contents are relatively simple to understand. They include a set of allowable frequency ranges; for each range, the maximum bandwidth, allowable power, and antenna gain are listed. There's also a set of flags for special rules; some domains, for example, do not allow outdoor operation or certain types of modulation. Each domain is associated with a two-letter identifying code which, normally, is just a country code.

There is a new mac80211 function which drivers can call to get the current regulatory domain information. But, unless the system has some clue of where on the planet it is currently located, that information will be for the "world domain," which, being designed to avoid offending spectrum authorities worldwide, is quite restrictive. Location information is often available from wireless access points, allowing the system to configure itself without user intervention. Individual drivers can also provide a "location hint" to the regulatory core, perhaps based on regulatory information written to a device's EEPROM by its vendor. If need be, the system administrator can also configure in a location by hand.

The database of domains and associated rules lives in user space, where it can be easily updated by distributors. When the name of the domain is set within the kernel, an event is generated for udev which, in turn, will be configured to run the crda utility. This tool will use the domain name to look up the rules in the database, then use a netlink socket to pass that information back to the kernel. From there, individual drivers are told of the new rules via a notifier function.

[PULL QUOTE: No distributors have made any policy plans public, but one assumes that the signing keys for the CRDA database will not be distributed with the system. END QUOTE] The database is a binary file which is digitally signed; if the signature does not match a set of public keys built into crda, then crda will refuse to use it. This behavior will protect against a corrupted database, but is also useful for keeping users from modifying it by hand. No distributors have made any policy plans public, but one assumes that the signing keys for the CRDA database will not be distributed with the system. We're dealing with free software, so getting around this kind of restriction will not prove challenging for even moderately determined users, but it should prevent some people from cranking their transmitted power to the maximum just to see what happens.

The CRDA mechanism, once merged into the kernel and once the wireless drivers actually start using it, should be enough to ensure that Linux systems with well-behaved users will be well-behaved transmitters. Whether that will be enough to satisfy the regulatory agencies (some of which have been quite explicit on their doubts about whether open-source regulatory code can ever be acceptable) remains to be seen. But it is about the best that we can do in a free software environment.

---

(Log in to post comments)

Am I the only one that thinks that it's not the kernel's responsibility to enforce local law?
Should the Linux Kernel prevent being used in any other illegal actions? Maybe stop speeding
cars? Avoid being used in Internet fraud? Refuse to participate in a murder?

It is clear that the system should be able to impose limitations, but those should be decided
by the system administrator, not by the system itself. Most users cannot tell the difference
between a kernel enforced policy and a userspace (but privileged) one. What's more, most users
wouldn't event want to. And for those who would, it's trivial to build an emitting device.
This solution solves effectively nothing. The FCC should be equally served by an interface
that allows userspace to set the policy as required.

One final thought: laws and regulations change, not only from place to place, but with time
too. 

I like this development because;

It makes it easier to comply with local laws; arrest and fines are annoying, especially when
travelling.

Perhaps in future intel wireless will no longer need non-free binary-blob firmware:

http://bughost.org/bugzilla/show_bug.cgi?id=1594

People with ham-radio and other licenses may be able to experiment with software radio stuff
while easily complying with their special license.

Presumably, people in general don't actually _wan't_ to break the law. As such, a computer
subsystem that try to keep you from unintentionally breaking the law should be seen as a good
thing.

Keep in mind that if you do want a device to emit radio waves at frequencies and powers that
are illegal in your current location, it is trivial to do so by simply using components that
can be bought for a small number of dollars at the nearest radio shack and information that
can be easily googled, or by making semi-trivial changes in a linux driver, or by slightly
altering the hardware itself.

I guess that the illusion of safety is more important than real safety here. If there is a
separate subsystem with cryptographically signed data about emission levels, that makes it
feel less open, less unrestricted, even if you in fact can just edit the source code a bit to
bypass the whole thing. Kind of like how the anti virus people want deep kernel hooks for
their anti virus products, even though there is nothing they can do with those that can't be
done by a pure user space solution. Kind of like how it has been repeatedly demonstrated that
there are many simple ways to get various weapons past airport security, but regular people
aren't even allowed to bring a bottle of shampoo.

Sometime security theater is the only thing that matters.

The good thing about this proposed subsystem is that it will actually make it easier to write
law abiding, bug free and stable drivers since it's suddenly much less work to find out at
what power you're allowed to transmit on a given frequency. So it serves a dual purpose of
both giving an illusion of safety and making the life of driver writers easier.

And hey, anything that will get this stupid policy deamon for my Intel wireless of my system
is a win in my book.

it's not the kernels responsibility to enforce the local law, but it is the users
responsibility to _comply_ with the local law.

and if the kernel doesn't provide reasonable tools to allow the user to comply with the local
laws then the kernel is at fault.

remember that if someone really wants to they can change the code (they have the source), and
that there are people who have legitimate reasons to operate outside the 'normal' rules (for
example Ham radio operators can use wifi equipment on channels that are not legal for other
people to use in the US)

> There's also a set of flags for special rules; some domains, for example, do not allow
outdoor operation or certain types of modulation.

Just out of interest, where in the world is outdoor operation restricted? And how does the
device know it's outside? I suspect I've missed something really obvious here, but I have to
ask...

> And how does the device know it's outside?

The user may be forced by law to tell the device/driver.

I am kind of replying to both previous comments here, so I appreciate I am not making fair
statements, but I'm just curious rather than trying to tell anyone they're wrong.

So in Belgium, people routinely make sure to tell their Pocket PDAs and similar gadgets they
are outside? And when they go back inside?

Or does no wireless device configured to know it's in Belgium ever use the lowest part of the
"a" domain at the higher power, just to be safe?

Or is this just a case of stupid legal distinctions which no one respects in practice?

Or - perhaps the most plausible guess - do portable devices never use that part of the domain
at the higher powered level, while mains powered and hence legally-presumably indoor devices
do?