From: Jeff Garzik <jgarzik@pobox.com>
To: Simon Barber <simon@devicescape.com>
Cc: Michael Buesch <mbuesch@freenet.de>,
Ben Greear <greearb@candelatech.com>,
David Hollis <dhollis@davehollis.com>,
"John W. Linville" <linville@tuxdriver.com>,
Samuel Ortiz <samuel.ortiz@nokia.com>,
netdev@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: wireless geo stuff (was Re: wireless-2.6 status (25 January 2006))
Date: Thu, 26 Jan 2006 21:15:53 -0500 [thread overview]
Message-ID: <43D98259.8090406@pobox.com> (raw)
In-Reply-To: <C86180A8C204554D8A3323D8F6B0A29FEB471D@dhost002-46.dex002.intermedia.net>
Simon Barber wrote:
> In order to get FCC certification the manufacturer must ensure there is
> no easy way for the user to tune to illegal frequencies. Broadcom has
> done their job - it was not easy to reverse engineer their driver. Now
> the cat is out of the bag. The open source driver is not illegal -
> although it may be illegal to use it - since the chipset and driver were
> likely certified together. I'm no expert in FCC regulation, so take all
> of this with a pinch of salt.
First, kernel developers should do the best they can to provide
facilities to limit the frequencies, including sane and safe defaults
for the softmac cases. It just makes sense to do that, from a "friendly
neighbor" and "don't operate out of spec" perspective, if nothing else.
It's damned _rude_ to use channels other than the ones selected by the
Responsible Authority. Some ham radio operator -- like me -- might be
using that frequency to carry on a pleasant Morse code conversation with
someone else halfway across the world. Linux software shalt not be
rude. :)
Second, if someone takes steps to disable these safeguards we build in,
that's akin to putting illegal crystals into a radio, or tuning a
transmitter to police/emergency bands.
Finally, binary-only software is clearly _not_ a barrier to this sort of
circumvention. Reverse engineering x86 software is a skill that's very
widespread, relative to other sorts of reverse engineering. Reverse
engineering tools for the x86 are very mature these days, having had two
decades to grow and flourish. If the _hardware_ can be programmed
maliciously, there's not a whole lot you can do about it... particularly
when the hardware manufacturer chooses a method of obfuscation (x86
code) practically designed for easy analysis.
Jeff
parent reply other threads:[~2006-01-27 2:16 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <C86180A8C204554D8A3323D8F6B0A29FEB471D@dhost002-46.dex002.intermedia.net>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43D98259.8090406@pobox.com \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dhollis@davehollis.com \
--cc=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mbuesch@freenet.de \
--cc=netdev@vger.kernel.org \
--cc=samuel.ortiz@nokia.com \
--cc=simon@devicescape.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).