From owner-freebsd-hardware@FreeBSD.ORG Fri Oct 6 03:00:41 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2E8D16A415 for ; Fri, 6 Oct 2006 03:00:40 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A2243D45 for ; Fri, 6 Oct 2006 03:00:39 +0000 (GMT) (envelope-from mureninc@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so707308wxd for ; Thu, 05 Oct 2006 20:00:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zf6M6mQGMsHQDk/M4RWTnaV5sBiIbyPLsnucR2sxS8Jls6KP1qDBmiHW5o+JyLr5W8OGWuB24YHWdPIwJTTZyhnkaK3QobPdJ1hZkVDHPr8x3IO+CV0hhdfQ5gIZN2cbMvDV2jsLSRb1zU6FMmF33rBCpezDvd7gbP07uufi37s= Received: by 10.70.76.11 with SMTP id y11mr4423064wxa; Thu, 05 Oct 2006 20:00:39 -0700 (PDT) Received: by 10.70.36.16 with HTTP; Thu, 5 Oct 2006 20:00:39 -0700 (PDT) Message-ID: Date: Thu, 5 Oct 2006 23:00:39 -0400 From: "Constantine A. Murenin" To: "John Baldwin" In-Reply-To: <200610051306.58843.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610050852.58943.jhb@freebsd.org> <200610051306.58843.jhb@freebsd.org> Cc: freebsd-hardware@freebsd.org Subject: Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 03:00:41 -0000 On 05/10/06, John Baldwin wrote: > On Thursday 05 October 2006 12:34, Constantine A. Murenin wrote: > > > you might want to ask Theo why he complains about Intel not giving him a > > > license for one binary blob (Intel wireless firmware) but complains about > > > Atheros providing a binary blob that he can distribute. Seems a bit of a > > > contradiction to me. However, you probably won't make any headway with > > > that argument because the other side won't be using reason and logic. > > > > Are you being serious? The distinction is rather clear -- Intel's > > firmware is processor and operating system independent and runs on the > > wireless microprocessor, whereas Atheros' HAL module is > > processor-dependent, and runs on the main CPU in kernel mode with > > unlimited priviledges (correct me if I'm wrong). Clear distinction > > here, IMHO. > > You do realize that on a PCI bus each device (like iwi(4), ipw(4), etc.) is a > busmaster, so the firmware on the hardware can DMA to anywhere in physical > memory? (Well, on some archs you have an IOMMU to deal with that can make > that a bit more tricky, but on i386 and amd64 you don't have that to worry > about.) Thus, malicious firmware could engage in kernel object modification, > etc. If you're worried about reviewing the source for security bugs, then > that worry should be applied to firmware as well as HALs. Taking that > argument even further, you really want to review the source for firmware the > OS never touches as well (such as on RAID controllers, em(4), etc.) since it > still has unmitigated access to all of RAM in the machine. That's still a > bit safer than firmware loaded by the OS (easier to sneak in rogue firmware > that way as it's loaded more often). Yes, world isn't perfect. But what is the probability that Intel Firmware can possibly do something other than a DoS attack on the host machine, as the machine may have ANY possible operating system on ANY platform? When you have a binary HAL, it's specific to the platform, and that makes the probability of some successful compromise much more plausible than with OS-independent firmwares. And let's not concentrate on just security, but also think of reliability and portability -- binary HALs create the necessity for the hardware manufacturer to update the blob for new platforms / operating systems / compilers / etc. Clearly, binary HALs require way much more hassle than do firmwares, which aren't required to be updated with any possible updates of the OS. > In fact, brining up ath(4) vs. iwi(4) > specifically: I happen to know the person who compiled the ath(4) HAL > personally and trust Sam quite a bit. I haven't the foggiest clue who wrote > or built or reviewed the iwi(4) firmware. Running iwi(4) (which I do) takes > significantly more "blind faith" for me than ath(4). I think you've just discredited yourself from being objective, as it's now just a matter of your own opinion aka bias of whom you trust and whom you don't trust. ;) Cheers, Constantine.