linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



           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).