From mboxrd@z Thu Jan 1 00:00:00 1970 From: Denis 'GNUtoo' Carikli Subject: Re: Free firmware - A redefinition of the term and a new metric for it's measurement. Date: Tue, 14 Feb 2017 13:15:48 +0100 Message-ID: <20170214131548.35dafcfc@second-laptop> References: Reply-To: Workgroup for fully free GNU/Linux distributions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gnu-linux-libre-bounces+gldg-gnu-linux-libre=m.gmane.org@nongnu.org Sender: "gnu-linux-libre" To: David Craven Cc: guix-devel , Workgroup for fully free GNU/Linux distributions List-Id: guix-devel.gnu.org On Fri, 3 Feb 2017 15:37:32 +0100 David Craven wrote: > 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. When using the Linux kernel, the firmwares are sometimes loaded by something else than the linux kernel: - In most Replicant devices, the modem firmware is in a separate eMMC partition in the device(Smartphone/Tablet), and it is loaded by libsamsung-ipc. - Some bootloaders such as u-boot have the ability to load some firmwares or FPGA bitstreams. > 2. The peripheral contains persistent storage containing the firmware > and uses a separate interface for flashing the firmware. This doesn't differenciate between a chip with internal non-voltaile memory, and a chip with external (potentially shared) flash chip. This can have some serious freedom privacy and security implications when the peripheral's firmware is on the same flash chip than the OS (GNU/Linux or Android/Replicant). In that case the processor running that non-free firmware can also access the OS partition. I think it is the case on some older qualcomm devices like the HTC Dream, where the modem firmware is on the same flash chip than the Android Operating system... On samsung smartphones and tablets supported by recent Replicant versions, libsamsung-ipc, which is a library that talks to the modem, loads the modem firmware. Thanks to that hardware architecture, the modem doesn't have access to the eMMC that holds the Android distribution (here Replicant). > Problem: > Today as an example, a WiFi card using option 2 is considered more > free than one using option 1. I understand the point, but let's approach the issue from another point of view to better understand its contradictions and the tradeoffs that have been made. Let's take it from a top-down perspective where the top is application software that runs on top of lower level software. Down goes deep down in the hardware, like down to how a resistor is made. If applications have to be free software (It's morally wrong not to respect the users freedom), the software that makes the hardware works also needs to be free software: - For the same reasons than applications have to be free software. - Since that software is more privileged it's very useful and important for it to be free software. - As you stated it also impacts the ability to use hardware beyond their end of life, which reduces waiste. Given the above one might wonder how deep we should go down and what is the fronteer between hardware and software. Given that even hardware and chip design has freedom privacy and security inplications it is desirable to have freedom there too. However given that we are not there I think that we need to have some criterias that are reachable. One can for instance use a computer that respects the FSF RYF criterias as of today. I am for instance using one to write this mail. My computer is not ideal though since: - Its hard disk has a non-free firmware - Its embedded controller has a non-free firmware Beside the fact that I added the tor-browser, all rest is RYF and FSDG compliant. The question for me is then how to use the acceptable/not-acceptable line to get more freedom out of it: - If redistributing (and using) non-free firmwares was: - still acceptable - not an issue in the FSDG guidelines - done in the FSDG compliant distributions Then we would probably: - Not have had the ath9k_htc firmware liberated (thanks to Thinkpenguin,Atheros and the people who made it possible) - May have more people using FSDG compliant distributions. Having the ath9k_htc firmware liberated was really really important, especially because: - The Intel WiFi cards present in many laptops require non-free firmware to work, at least with recent kernels. - Many laptop boot-firwmare(BIOS, UEFI) will refuse to boot if the user either changed the wifi card like with the default BIOS of the Lenovo Thinkpad X60 and X200, or removed it like with at least one of the HP Envy laptops. - The ath9k_htc compatible cards can still be bought and found and have been for a long time. - The ath9k_htc compatible cards supports modern-enough WiFi standards. With that we can still use WiFi by ignoring the intel wifi card and using an USB wifi card instead. There are also free software firmware to support some other peripherals such as: - Old b43 compatible wifi cards (OpenFWWF). - keyspan compatible devices. - Older atheros based USB wifi cards. - Probably few other devices. While this is really great and that each new free firmware is a great achievement and is really important, they are also crucial because we failed: - ATI GPUs are almost unusable with free software, in the best case we can load the radeon driver but do not have 3D accelerations and many of the features of that driver working because of the lack of a free firmware. - Intel WiFi cards are a pain, the user has to go buy new USB WiFi cards. I think that the solution is not to make the use and redistribution of such non-free firmwares okay, instead we should find way to make some people work to replace them with free software: - Intel WiFi Cards: The idea if and which ones can work without a non-free firmware. The easiest way to do it is to: 1) Look in h-node which intel WiFi cards work 2) Try to reproduce it and make them work with the same setup 3) Try to understand why they work 4) Try to forward-port what makes them work in recent linux-libre and send the patch upstream, to linux-libre (or linux if applicable). - Radeon GPUs: The people working on porting GNU/Linux to the Sony Playstation 4 have tools to work with radeon firmwares, and probably enough understanding and documentation to be able to create free software firmwares: https://github.com/fail0verflow/radeon-tools.git Theses are not the only hardware-related issues with reguard to free software, however they impact *a lot* of people, directly if they use FSDG distributions and harve hardware not supported by free software because of non-free firmwares, or indirectly because they cannot use such hardware or distributions. > Implications on Security: [...] Hardware design also has huge implications on security. Some busses allow access to the RAM used by the main processor, which holds the linux kenrel and other programs being executed... Preventing peripherals to access all of the memory is possible but depends on a lot of factors. With the PCI and derivated busses to work we need the following: - In the case of x86 computers, the hardware has to have an IOMMU, and that IOMMU has not to be flawed to allow PCI devices to bypass it. - The operating system needs to configure the IOMMU correctly. - In the case of AMD devices, the boot firmware(BIOS/UEFI) needs to have IVRS ACPI tables that contains part of the configuration of the IOMMU. - If the devices are enabled at boot, the boot firmware needs to setup the IOMMU before the RAM is initialized and accesible to the devices on the PCI/PCIe bus. To get more information on the availability of such feature on common computers, see https://www.qubes-os.org/hcl/ When taking security seriously, the fact that a non-free firmware is running in peripherals that can have access to the main system's RAM has to be taken into account. However I don't have a clear idea on whether it has to be dealt with within free software policies or not, and how much it is in the scope of free software. I don't think we, as the free software community, can ignore it as it means that some non-free code can take control of your computer... For instance in Replicant, we decided not to focus on devices that can permit non-free firmwares to take control of the main processor, and instead to prioritize work on devices where the hardware doesn't have any physical ways to allow a non-free firmware to access the main processor's RAM. Even if I disagree with your suggestion below, as I think it might not be the best strategy, I'll give some input nevertheless. For me the best strategy would be to have some people work on the technical issues not to have to adjust policies backward and allow more and more non-free software. If we have enough free firmwares, many GNU/Linux distributions may consider getting rid of non-free firmwares entierely. Making loadable and non-loadable firmwares policies consistent would then makes a lot of sense as it would probably have a good impact on freedom. We might also be able to leverage loadable firmwares code to make other peripherals with non-loadable-by-a-host-computer firmwares work. > 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. Freely redistributable firmwares often have conditions that I find unacceptable. The validity of such conditions then depends on the jurisdiction you live in. Many have no-modification and no-reverse-engineering clauses. > 2. The firmware can be loaded using the standard kernel api and the > device does not contain any internal storage. You might want to consider the following alternative: - The firmware can be loaded using free software and the device does not contain any internal storage. - The firmware can be loaded using free software and the device does not contain any internal storage for code. - The firmware can be loaded using free software and the device does not contain any internal storage that can be used for other purposes than storing documented configuration data. The last two alternatives contains takes into account the storage of data such as the MAC Address and calibration data of network devices. > 3. There is documentation available that enables the developement of > free firmware. - There is sufficent documentation available to permit the development of a free firmware. - There is sufficent documentation available to permit the development of a free firmware, and to be able to understand the freedom/security/privacy implication of that hardware. The later might be interesting to: - Make sure that an IOMMU works correctly. - Have an idea of what the management engine bootrom does. - Have an idea of what a CPU does to the data during context switch. - Have an idea of the risk associated with the use of a network interface chip like the Intel e1000e: - Where is a firmware supposed to be stored, can you be sure that the card runs no firmware? - What a remote computer might be able to do to the chip? - Know if an external pc-card can access your main processor's RAM if you didn't load drivers that enable it. - Know which peripherals or busses have access to your RAM while your operating system is not started yet. - Know if a bus or device allow DMA: - Make sure that a superIO doesn't allow DMA access to the main processor's RAM in the dock connector of a laptop. - Make sure that the PCI lanes aren't exported on a dock connector of a laptop. Denis.