From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Free firmware - A redefinition of the term and a new metric for it's measurement. Date: Fri, 3 Feb 2017 15:37:32 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZezY-0006k0-F0 for guix-devel@gnu.org; Fri, 03 Feb 2017 09:37:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZezX-0002Cq-Ar for guix-devel@gnu.org; Fri, 03 Feb 2017 09:37:36 -0500 Received: from mail-qt0-x22a.google.com ([2607:f8b0:400d:c0d::22a]:34173) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZezX-0002Ch-6g for guix-devel@gnu.org; Fri, 03 Feb 2017 09:37:35 -0500 Received: by mail-qt0-x22a.google.com with SMTP id w20so36833074qtb.1 for ; Fri, 03 Feb 2017 06:37:35 -0800 (PST) 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: gnu-linux-libre@nongnu.org, guix-devel Motivation: We want to be able to exercise our freedoms in all parts of our computing systems. This leads to the benefits of higher security and maintaining hardware devices after their end of life. Background: All peripheral devices work roughly the same. Host Controller Interface <-> Link Layer <-> Physical Layer The physical layer is a mixed signal circuit responsible for implementing the electrical interface of the device. The boundary between LL and PHY is a clock domain crossing. The PHY layer is implemented entirely in hardware and is fixed in silicone. The link layer is implemented either in digital logic also fixed in silicone or in complex peripherals partially in firmware. HCI <-> Microcontroller <-> Digital logic <-> PHY This leads to two models of loading the firmware that runs on the MCU. 1. The peripheral does not contain persistent storage and the firmware is loaded by the linux kernel through a standard API. 2. The peripheral contains persistent storage containing the firmware and uses a separate interface for flashing the firmware. Problem: Today as an example, a WiFi card using option 2 is considered more free than one using option 1. Implications on Security: While in the first case we can check the hash of the binary blob and be certain that the binary blob we are providing is what is running on the device, in the second case we do not even have that guarantee. A malicious party can reflash the firmware and no one would ever know. Security through obscurity is no security at all. Just as important a threat to security as a malicious party is human error. With the second model there is no simple way to fix vulnerabilities even if the vendor is aware and willing to fix it. Implications on Freedom: This also makes it much harder to write, debug and distribute free firmware if such where available. Solution: We need to encourage and allow option 1 as opposed to option 2. Hardware suggestions by the FSF should instead of focusing on a black and white - needs binary blobs or does not need binary blobs - focus on the following: 1. The firmware is freely redistributeable - allowing free software distributions to redistribute the firmware as opposed to the user having to download the firmware themselves and accept arbitrary terms and conditions. 2. The firmware can be loaded using the standard kernel api and the device does not contain any internal storage. 3. There is documentation available that enables the developement of free firmware.