The Ethics of Microcode: When Control Matters More Than Tech

Tue, 13 Aug 2024

The inspiration for this blog post struck during a recent conversation about CPU microcode.

In my past writings, I have consistently argued that proprietary software represents an inherent injustice. It mistreats users by systematically denying them the essential freedoms they deserve to exercise control over their computing. This fundamental control issue lies at the heart of the free software movement. It's a binary choice - either the user holds the reins, or the developer does. There's no middle ground; it's always one or the other.

Intel and AMD's CPU microcode is software and non-free software at that (look at the license). Thus, it should be free for all the same reasons as any other kind or type of program. We used to have free microcode, on the PDP-10 computer, but it's been lost with newer processors.

Understanding the Players: Microcode vs. Micro-Operations

Intel or AMD Microcode: Essentially firmware embedded within CPUs, microcode translates complex instructions into simpler micro-operations that the processor can execute. Intel and AMD periodically release microcode updates, often to address bugs or security vulnerabilities. However, these updates are proprietary, non-free software, denying users the control they deserve.
ARM Micro-Operations: ARM CPUs also employ micro-operations, but they are generated dynamically by the processor as part of its standard instruction processing. Unlike Intel or AMD's microcode, ARM's micro-operations are not separate software entities subject to external updates or control.

While micro-operations also involve abstraction, they fundamentally differ from Intel's or AMD's microcode. They are an intrinsic part of the CPU's design. It can be treated like hardware because replacing the CPU is the only way to implement changes.

The central ethical concern lies in the principle of user control. The free software movement argues that users should be free to understand, modify, and share the software they use.

Intel or AMD's Microcode: Proprietary microcode updates directly challenge this principle. By denying users their rights under software freedom, Intel and AMD effectively control a fundamental aspect of their computing and contribute to a general erosion of user rights.
ARM's Micro-Operations: While ARM's micro-operations involve a degree of abstraction, they do not present the same ethical concerns as Intel or AMD's microcode. Users retain control over the software running on their ARM CPUs without being subject to external updates or proprietary control mechanisms.

While Intel and AMD's built-in microcode and ARM's micro-operations are technically different, that difference doesn't matter for this context: They can converge on an ethical plane when user control is the central focus. Using that focus, rejecting microcode updates is a conscious choice to maintain control over one's computing. By rejecting microcode updates, users refuse to participate in a system that undermines their autonomy where others can update their software, but the user can't. In doing so, the user can reclaim some level of autonomy. This act aligns ethically with using an ARM CPU, where the user is not subjected to that external control. When the matter of microcode updates is removed from the picture because the user categorically rejects the notion that only a third party should be allowed to update their software and recognizes that as the power grab that it is, replacing the CPU is the only way to implement changes, just as with ARM. The developer and user control level over the CPU becomes the same in both cases. From an ethical perspective, rejecting microcode updates and using an ARM CPU can be considered ethically equivalent. In this case, where we've reached ethical equivalence, one of the CPUs is not "freer" than the other; they're ethically equivalent, even if not technically.

But this argument about ethical equivalence only goes so far - it only holds up if one rejects the updates. If one's installing or distributing the updates, they can't avail themselves of this argument. In fact, distributing them makes the distributor an accomplice in this battle over control of our computing and just as worthy of criticism.

Despite being able to reach a point of ethical equivalence, which is a start, it's not enough. The ideal scenario would involve free microcode software that users can control and update like any other, and we used to have that. While we may not have resurrected that yet, this ethical discussion highlights the importance of striving for greater user control and resisting any attempts to impose external control with a third party being able to generate updates, while the user is being denied that. If we aren't allowed to make our updates, the very first thing we should do is deny the developer that same ability by rejecting their updates. Otherwise, the developer will have more control than we do - and that's wrong. It's a reminder that in the world of technology, ethics matters even more than technical matters.

In fact, in the fast-paced world of technology, it's easy to listen to certain people talking about things from a technical point of view and get swept up in bug fixes, security vulnerabilities, or other matters. However, it's essential to pause and consider the ethical implications before diving headfirst into the technical details. By prioritizing ethical evaluation, we ensure our evaluations align with our values. Not doing this can lead to unintended consequences. Remember, software should be controlled by those who use it, not vice versa. So, let's make ethical considerations an integral part of our technological journey and positively impact the world.