To update blobs or not to update blobs(codon.org.uk)
codon.org.uk
To update blobs or not to update blobs
https://codon.org.uk/~mjg59/blog/p/to-update-blobs-or-not-to-update-blobs/
5 comments
I think this comes from this Mastodon thread, https://snac.lx.oliva.nom.br/lxo/p/1771789687.181567
They do talk past each other a bit, and I find it difficult to follow, but overall, I'm more sympathetic to Garrett's position than Oliva's.
As far as I understand: GNU Linux-libre, a distribution, excludes the ability to update proprietary CPU microcode. Oliva, an important Linux-libre maintainer, says that (e.g.) Intel's proprietary microcode is inherently a backdoor, and that the ability to replace it only with new proprietary microcode is also a backdoor and an attack. Furthermore, new microcode updates cannot plausibly benefit the user and may only cause further harm to the user, thus Linux-libre (as distributed) makes efforts not to facilitate them.
Garrett is arguing against this notion, saying that microcode updates can very plausibly benefit the user in ways that cannot be mitigated in higher layers; that there have been no publicly-known cases of a microcode update introducing security vulnerabilities that were not already present; and thus, that it is beneficial to the user to have the ability (but not the requirement!) to update microcode blobs.
Both of them seem to agree it is better to have free software over proprietary blobs in all components of the system, though they both accuse each other of not fully standing for that position (Oliva accuses Garrett of "overlooking" the inherent backdoor nature of proprietary microcode; and Garrett takes issue with Olivia treating "installable software" as ethically distinct from firmware ROMs w.r.t. software freedom).
Personally, I'm not a fan of software or libraries that take active measures to make me use them in a certain way, so I'd lean toward Garrett's position, but thankfully no one is forcing me to use Linux-libre.
As far as I understand: GNU Linux-libre, a distribution, excludes the ability to update proprietary CPU microcode. Oliva, an important Linux-libre maintainer, says that (e.g.) Intel's proprietary microcode is inherently a backdoor, and that the ability to replace it only with new proprietary microcode is also a backdoor and an attack. Furthermore, new microcode updates cannot plausibly benefit the user and may only cause further harm to the user, thus Linux-libre (as distributed) makes efforts not to facilitate them.
Garrett is arguing against this notion, saying that microcode updates can very plausibly benefit the user in ways that cannot be mitigated in higher layers; that there have been no publicly-known cases of a microcode update introducing security vulnerabilities that were not already present; and thus, that it is beneficial to the user to have the ability (but not the requirement!) to update microcode blobs.
Both of them seem to agree it is better to have free software over proprietary blobs in all components of the system, though they both accuse each other of not fully standing for that position (Oliva accuses Garrett of "overlooking" the inherent backdoor nature of proprietary microcode; and Garrett takes issue with Olivia treating "installable software" as ethically distinct from firmware ROMs w.r.t. software freedom).
Personally, I'm not a fan of software or libraries that take active measures to make me use them in a certain way, so I'd lean toward Garrett's position, but thankfully no one is forcing me to use Linux-libre.
After reading that thread I immediately though - Why is there always that guy yelling "But the extreme case doesn't hold, therefore it's invalid"
They just come off as an uninformed troll - the truth is it is very rare in life that any single thing meets the perfect solution.
The best anyone can do is make an effort to move toward that goal whilst we look for better solutions AND we move away from solutions that are definitely not working in the direction of better solutions.
In this case, we know for a fact that obscurity is a weaker and worse solution to open and honest security postures (for the most part), and the fact that we have the /opportunity/ to inspect things is infinitely better than not having that choice at all.
They just come off as an uninformed troll - the truth is it is very rare in life that any single thing meets the perfect solution.
The best anyone can do is make an effort to move toward that goal whilst we look for better solutions AND we move away from solutions that are definitely not working in the direction of better solutions.
In this case, we know for a fact that obscurity is a weaker and worse solution to open and honest security postures (for the most part), and the fact that we have the /opportunity/ to inspect things is infinitely better than not having that choice at all.
Which of the two are you referring to
> [?]Light » 2026-02-22
@[email protected]
@lxo Do you genuinely honestly actually audit the source code of every single piece of software running on your system and compile it all yourself, including web code? Either you have a lot of time on your hands and a lot of skill, or you're running a very minimal system, or you actually don't.
... [?]Light » 2026-02-22 @[email protected]
@lxo And even if you do, most people* can't. So for them, they need third-party audits, which as I have previously pointed out, can be done without source code. Or otherwise they try to get their software from sources they trust.
*For example, rocket scientists and brain surgeons
2 0 ↺ [?]Alexandre Oliva » 2026-02-22 @[email protected]
I don't have to. that's the power of community. security doesn't work in absolutes, and auditability is an imperfect deterrent, but it's infinitely better than the moves to prevent auditability that hostile vendors adopt
I do audit the rare cases of web blobs that are imposed on me, because I can't count on community for those, and my security depends on it even when my freedom has been unjustly taken away
... [?]Light » 2026-02-22 @[email protected]
@lxo Then you personally know other programmers that you trust to audit it for you. Again, most people don't have that.
... 2 0 ↺ [?]Alexandre Oliva » 2026-02-22 @[email protected]
that's missing the point. auditability alone is already quite a deterrent. that some of us actually engage in auditing is a bonus that benefits everyone, even if it doesn't happen very often. it's kind of the panopticon effect, but for the better.
@lxo Do you genuinely honestly actually audit the source code of every single piece of software running on your system and compile it all yourself, including web code? Either you have a lot of time on your hands and a lot of skill, or you're running a very minimal system, or you actually don't.
... [?]Light » 2026-02-22 @[email protected]
@lxo And even if you do, most people* can't. So for them, they need third-party audits, which as I have previously pointed out, can be done without source code. Or otherwise they try to get their software from sources they trust.
*For example, rocket scientists and brain surgeons
2 0 ↺ [?]Alexandre Oliva » 2026-02-22 @[email protected]
I don't have to. that's the power of community. security doesn't work in absolutes, and auditability is an imperfect deterrent, but it's infinitely better than the moves to prevent auditability that hostile vendors adopt
I do audit the rare cases of web blobs that are imposed on me, because I can't count on community for those, and my security depends on it even when my freedom has been unjustly taken away
... [?]Light » 2026-02-22 @[email protected]
@lxo Then you personally know other programmers that you trust to audit it for you. Again, most people don't have that.
... 2 0 ↺ [?]Alexandre Oliva » 2026-02-22 @[email protected]
that's missing the point. auditability alone is already quite a deterrent. that some of us actually engage in auditing is a bonus that benefits everyone, even if it doesn't happen very often. it's kind of the panopticon effect, but for the better.