https://mjg59.dreamwidth.org/70895.html
Account name: [ ] Password [ ] [Log in]
(OpenID?) (Forgot it?) [ ] Remember Me
You're viewing [personal profile] mjg59's journal
Create a Dreamwidth Account Learn More
[ ] [Interest ] [Go]
Reload page in style: site light
Matthew Garrett
When should we require that firmware be free?
When should we require that firmware be free?
Dec. 12th, 2024 01:17 pm
[personal profile] mjg59
The distinction between hardware and software has historically been
relatively easy to understand - hardware is the physical object that
software runs on. This is made more complicated by the existence of
programmable logic like FPGAs, but by and large things tend to fall
into fairly neat categories if we're drawing that distinction.
Conversations usually become more complicated when we introduce
firmware, but should they? According to Wikipedia, `Firmware is
software that provides low-level control of computing device
hardware', and basically anything that's generally described as
firmware certainly fits into the "software" side of the above
hardware/software binary. From a software freedom perspective, this
seems like something where the obvious answer to "Should this be
free" is "yes", but it's worth thinking about why the answer is yes -
the goal of free software isn't freedom for freedom's sake, but
because the freedoms embodied in the Free Software Definition (and by
proxy the DFSG) are grounded in real world practicalities.
How do these line up for firmware? Firmware can fit into two main
classes - it can be something that's responsible for initialisation
of the hardware (such as, historically, BIOS, which is involved in
initialisation and boot and then largely irrelevant for runtime[1])
or it can be something that makes the hardware work at runtime (wifi
card firmware being an obvious example). The role of free software in
the latter case feels fairly intuitive, since the interface and
functionality the hardware offers to the operating system is
frequently largely defined by the firmware running on it. Your wifi
chipset is, these days, largely a software defined radio, and what
you can do with it is determined by what the firmware it's running
allows you to do. Sometimes those restrictions may be required by
law, but other times they're simply because the people writing the
firmware aren't interested in supporting a feature - they may see no
reason to allow raw radio packets to be provided to the OS, for
instance. We also shouldn't ignore the fact that sufficiently
complicated firmware exposed to untrusted input (as is the case in
most wifi scenarios) may contain exploitable vulnerabilities allowing
attackers to gain arbitrary code execution on the wifi chipset - and
potentially use that as a way to gain control of the host OS (see
this writeup for an example). Vendors being in a unique position to
update that firmware means users may never receive security updates,
leaving them with a choice between discarding hardware that otherwise
works perfectly or leaving themselves vulnerable to known security
issues.
But even the cases where firmware does nothing other than initialise
the hardware cause problems. A lot of hardware has functionality
controlled by registers that can be locked during the boot process.
Vendor firmware may choose to disable (or, rather, never to enable)
functionality that may be beneficial to a user, and then lock out the
ability to reconfigure the hardware later. Without any ability to
modify that firmware, the user lacks the freedom to choose what
functionality their hardware makes available to them. Again, the
ability to inspect this firmware and modify it has a distinct benefit
to the user.
So, from a practical perspective, I think there's a strong argument
that users would benefit from most (if not all) firmware being free
software, and I don't think that's an especially controversial
argument. So I think this is less of a philosophical discussion, and
more of a strategic one - is spending time focused on ensuring
firmware is free worthwhile, and if so what's an appropriate way of
achieving this?
I think there's two consistent ways to view this. One is to view free
firmware as desirable but not necessary. This approach basically
argues that code that's running on hardware that isn't the main CPU
would benefit from being free, in the same way that code running on a
remote network service would benefit from being free, but that this
is much less important than ensuring that all the code running in the
context of the OS on the primary CPU is free. The maximalist position
is not to compromise at all - all software on a system, whether it's
running at boot or during runtime, and whether it's running on the
primary CPU or any other component on the board, should be free.
Personally, I lean towards the former and think there's a reasonably
coherent argument here. I think users would benefit from the ability
to modify the code running on hardware that their OS talks to, in the
same way that I think users would benefit from the ability to modify
the code running on hardware the other side of a network link that
their browser talks to. I also think that there's enough that remains
to be done in terms of what's running on the host CPU that it's not
worth having that fight yet. But I think the latter is absolutely
intellectually consistent, and while I don't agree with it from a
pragmatic perspective I think things would undeniably be better if we
lived in that world.
This feels like a thing you'd expect the Free Software Foundation to
have opinions on, and it does! There are two primarily relevant
things - the Respects your Freedoms campaign focused on ensuring that
certified hardware meets certain requirements (including around
firmware), and the Free System Distribution Guidelines, which define
a baseline for an OS to be considered free by the FSF (including
requirements around firmware).
RYF requires that all software on a piece of hardware be free other
than under one specific set of circumstances. If software runs on (a)
a secondary processor and (b) `within which software installation is
not intended after the user obtains the product', then the software
does not need to be free. (b) effectively means that the firmware has
to be in ROM, since any runtime interface that allows the firmware to
be loaded or updated is intended to allow software installation after
the user obtains the product.
The Free System Distribution Guidelines require that all non-free
firmware be removed from the OS before it can be considered free. The
recommended mechanism to achieve this is via linux-libre, a project
that produces tooling to remove anything that looks plausibly like a
non-free firmware blob from the Linux source code, along with any
incitement to the user to load firmware - including even removing
suggestions to update CPU microcode in order to mitigate CPU
vulnerabilities.
For hardware that requires non-free firmware to be loaded at runtime
in order to work, linux-libre doesn't do anything to work around this
- the hardware will simply not work. In this respect, linux-libre
reduces the amount of non-free firmware running on a system in the
same way that removing the hardware would. This presumably encourages
users to purchase RYF compliant hardware.
But does that actually improve things? RYF doesn't require that a
piece of hardware have no non-free firmware, it simply requires that
any non-free firmware be hidden from the user. CPU microcode is an
instructive example here. At the time of writing, every laptop listed
here has an Intel CPU. Every Intel CPU has microcode in ROM,
typically an early revision that is known to have many bugs. The
expectation is that this microcode is updated in the field by either
the firmware or the OS at boot time - the updated version is loaded
into RAM on the CPU, and vanishes if power is cut. The combination of
RYF and linux-libre doesn't reduce the amount of non-free code
running inside the CPU, it just means that the user (a) is more
likely to hit since-fixed bugs (including security ones!), and (b)
has less guidance on how to avoid them.
As long as RYF permits hardware that makes use of non-free firmware I
think it hurts more than it helps. In many cases users aren't guided
away from non-free firmware - instead it's hidden away from them,
leaving them less aware that their freedom is constrained.
Linux-libre goes further, refusing to even inform the user that the
non-free firmware that their hardware depends on can be upgraded to
improve their security.
Out of sight shouldn't mean out of mind. If non-free firmware is a
threat to user freedom then allowing it to exist in ROM doesn't do
anything to solve that problem. And if it isn't a threat to user
freedom, then what's the point of requiring linux-libre for a Linux
distribution to be considered free by the FSF? We seem to have ended
up in the worst case scenario, where nothing is being done to
actually replace any of the non-free firmware running on people's
systems and where users may even end up with a reduced awareness that
the non-free firmware even exists.
[1] Yes yes SMM
Tags:
* advogato,
* fedora
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
---------------------------------------------------------------------
* 9 comments
* Reply
---------------------------------------------------------------------
Flat | Top-Level Comments Only
It stops hardware cloning
Date: 2024-12-12 06:30 pm (UTC)
From: (Anonymous)
My primary use of non-free firmware is to stop free riding by
hardware cloners. It really sucks to put a lot of effort into a
hardware and software design, then have your product get cloned using
your own firmware. And in the worst cases, the people buying the
clones don't know they are clones and and then they expect the
initial company to provide support and get mad at them when things
don't work right.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
Re: It stops hardware cloning
Date: 2024-12-17 08:59 pm (UTC)
From: (Anonymous)
There is a large amount of software in the Console Modification
market that comes with little hints and nudges that if you didn't get
it from somewhere legit, you're probably running a clone. One
hardware trick that a friend of mine came up with is clever: A series
of 0Ohm resistors. Each batch gets sent out with a different one and
they're just the Luhn digit for YYYYMM of manufacture, which is
silkscreened onto the board through some Gerber mangling.
he's caught 2-3 people cloning his stuff b/c the Luhn digit will be
wrong for the recorded YYYYMM. Instead of getting mad at them, he
reaches out to them and offers them a licensing deal ("you get legit
gerbers every two months marking that you made it, you must not
distribute them, etc") for some reasonable cost ($0.10/board made)
and he gets a kickback of 50% of the raw profit from the sale. He
also offers a $0 "send me a clone I haven't seen yet and I will send
you a legit one" exchange.
Works out pretty well for him, but he works in a Niche of a Niche in
automation. He sells maybe 100 of the things a year.
* Link
* Reply
* Thread from start
* Parent
No upload, no future freedom
Date: 2024-12-13 03:20 am (UTC)
From: (Anonymous)
A point I think you fail to touch on is that if a firmware is burnt
into a rom with no means to replace it then you can't replace that
non-free firmware with a Free one. Clearly it would be best if the
manufacturers supplied a Free firmware in the first place but it's a
non-trivial number of useful devices which have had Free firmwares
written for them later.
* Link
* Reply
* Thread
* Hide 2 comments
* Show 2 comments
Burnt into a ROM
Date: 2024-12-13 06:57 pm (UTC)
bens_dad: (Default)
From: [personal profile] bens_dad
Depends whether the ROM is socketed or not.
At one time there were (closed source) ROMS for VW engine management
systems available in the classified ads in the back of car magazines.
IIUC, VW usually shut these guys down by hiring them - which may be
how they had the staff to implement DieselGate :-(
Edited (typos) Date: 2024-12-13 06:58 pm (UTC)
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 1 comment
* Show 1 comment
Re: Burnt into a ROM
Date: 2024-12-15 08:32 am (UTC)
From: (Anonymous)
Socketed ROM is not something that even exists in 2024. Not on the
class of devices we're talking about here.
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2024-12-13 06:53 pm (UTC)
bens_dad: (Default)
From: [personal profile] bens_dad
`RYF requires that all software on a piece of hardware be free other
than under one specific set of circumstances. If software runs on (a)
a secondary processor and (b) "within which software installation is
not intended after the user obtains the product", then the software
does not need to be free. (b) effectively means that the firmware has
to be in ROM, since any runtime interface that allows the firmware to
be loaded or updated is intended to allow software installation after
the user obtains the product.'
Hard disk drives* and SSDs have user-upgradable firmware, eg https://
www.guidingtech.com/53580/upgrade-ssd-firmware-windows/#
h-how-to-upgrade-the-firmware-of-your-ssd. So an RYF compliant
computer will have an open source compiler for writing the firmware
for the storage devices :-)
*I experienced this first-hand around 2000 with a department full of
IBM/Hitachi [S:Death:S]DeskStar drives.
* Link
* Reply
no subject
Date: 2024-12-14 09:12 am (UTC)
From: (Anonymous)
`there's enough that remains to be done in terms of what's running on
the host CPU'
Which software would you put into this category?
* Link
* Reply
no subject
Date: 2024-12-15 08:31 am (UTC)
From: (Anonymous)
Well, you are right in some aspect. But you have missed some
important points.
1. I have always considered "blob-cleaned" distros (I may be wrong)
as nothing more than as an art performance kinda https://
en.wikipedia.org/wiki/Petr_Pavlensky#Fixation_(2013) . They are
not meant to be practically usable. They are meant to demonstrate
in clear the non-free nature of present-day (2024-12-15) hardware
and software ecosystem, that if we clean all non-free software
vendors coerce us to run, then we cannot have working hardware.
It is nothing more. When somebody clams "I'm a free person, I
live in a free country and run free software" - you just point
him "I really hope that at least you are free not to run any
software with nobody fully knows what malware in them, but it
seems there is no much options for you to run other than Linux
Libre and GNU Hurd".
2. RYF has the opposite goal. It is also not designed to be anyhow
usable. Its purpose is just to show that in principle it can be
achieved with enough resources lumped into that direction, what
is lacked is the amount of resources of the kinds needed.
For more practical purposes we need not Linux Libre. We need working
and resource-efficient interactive decompilers and reversing IDEs,
like IDA Pro, but free ones. We cannot really trust Hex Rays inc.
Especially after Ilfak has sold it. Our best bet is retdec, I guess.
Ghidra by NSA... thanks, no.
* Link
* Reply
CAPTCHA
Date: 2024-12-17 04:39 pm (UTC)
From: (Anonymous)
Why would you require a CAPTCHA just to view a blog? Are you really
worried about a few thousand extra page-views from bots? I understand
protecting comments, but locking viewing of your blog behind a wall
is just silly. It's really annoying for people using non-mainstream
browsers, and generally hurts Internet interoperability.
* Link
* Reply
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
* 9 comments
* Reply
Flat | Top-Level Comments Only
Profile
Matthew Garrett
About Matthew
Power management, mobile and firmware developer on Linux. Security
developer at Aurora. Ex-biologist. [personal profile] mjg59 on
Twitter. Content here should not be interpreted as the opinion of my
employer. Also on Mastodon.
Page Summary
* (Anonymous) - It stops hardware cloning
* (Anonymous) - No upload, no future freedom
* [personal profile] bens_dad - (no subject)
* (Anonymous) - (no subject)
* (Anonymous) - (no subject)
* (Anonymous) - CAPTCHA
Expand Cut Tags
No cut tags
Top of page