From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI. Date: Thu, 2 Feb 2017 21:41:59 +0100 Message-ID: <20170202214159.2901d3e4@scratchpost.org> References: <20170201233531.2640-1-david@craven.ch> <20170201233531.2640-7-david@craven.ch> <20170202202006.03597708@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZOCn-0004MS-VG for guix-devel@gnu.org; Thu, 02 Feb 2017 15:42:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZOCk-0000k7-Lq for guix-devel@gnu.org; Thu, 02 Feb 2017 15:42:10 -0500 Received: from dd1012.kasserver.com ([85.13.128.8]:39871) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cZOCk-0000jO-F4 for guix-devel@gnu.org; Thu, 02 Feb 2017 15:42:06 -0500 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: David Craven Cc: guix-devel Hi David, On Thu, 2 Feb 2017 21:18:06 +0100 David Craven wrote: > > I don't think the firmware needs to be uploaded at all to the AR9285 de= vice. =20 >=20 > I don't understand: >=20 > 1. free firmware - anyone can update the firmware > 2. binary blob - the vendor can update the firmware > 3. fixed at manufacturing time - no one can update the firmware >=20 > Option 1 is obviously superior to the other two. But how is option 3 > better than option 2? When it's option 3 then you personally can't be targeted without also targe= ting anyone else that could have bought that chip. With option 2 the vendor could create malicious firmware just for you - unb= eknownst to you, of course.=20 If the firmware is actually fixed and constant (option 3), the company has = a very large disincentive to do anything bad to it. For example, let's say Intel had non-updateable microcode on its CPUs and i= t included a backdoor. If anyone *ever* found it, nobody would trust Intel = ever again - and Intel couldn't sweep it under the rug because millions of = physical chips that include the backdoor would be in the hands of different= people. What could they do? On the other hand, if firmware is updateable by a (possibly automated) prog= ram, that program could easily check whether it's running on *your* compute= r specifically and then give you a special firmware. Now nobody but you has= a chance to find it. Not to mention checking the date etc. With all the spying going on that's a *real* possibility. Also, many people= already found backdoors in BIOS updates for example - so it's not theoreti= cal. So that were the life-and-death things. =46rom an engineering (integrator) standpoint a fixed firmware is also better= since it doesn't change. So as an engineer you find out once and for all w= hat it does now and it will continue doing that forever. Moreover, the vend= or has an incentive to actually test the thing and fix all the showstoppers= *before* selling you the device. With option 2, they really don't (and als= o could change their mind at any time after the sale (!)).