Brief items

Thus a typical SoC mask set starts with lots of extra features, spare logic, and debug facilities that are chiseled away (disused) until the final shape of the SoC emerges. As Michelangelo once said “every block of stone has a statue inside it, and it is the task of the sculptor to discover it,” we could say “every SoC mask set has a datasheet inside it, and it is the task of the validation team to discover it”. Sometimes the final chisel blow happens at boot: an errant feature may be turned off or patched over by pre-boot code that runs even before the CPU executes its first instruction. As a result, even the best documented SoCs will have a non-trivial fraction of transistors that are disused and unaccountable, theoretically invisible to end users.

From a security standpoint, the presence of such “dark matter” in SoCs is worrisome. Forget worrying about the boot ROM or CPU microcode – the BIST (Built in Self Test) infrastructure has everything you need to do code injection, if you can just cajole it into the right mode. Furthermore, SoC integrators all buy functional blocks such as DDR, PCI, and USB from a tiny set of IP vendors. This means the same disused logic motifs are baked into hundreds of millions of devices, even across competing brands and dissimilar product lines. Herein lies a hazard for an unpatchable, ecosystem-shattering security break!

Technologically illiterate bureaucrats who have no clue at all, insisting that if they just "work together" with the tech industry, some magic golden key will be found. This is not how any of this works. Introducing a backdoor into encryption is introducing a massive, dangerous vulnerability that basically takes the secure walls of a house and rams a giant tank through the side. It's not adding a special key for law enforcement. It's breaking the very foundation of how end-to-end encryption works, and introducing a wide variety of shaky dangerous elements that they insist will never get exploited. But, with encryption, any vulnerability inevitably gets exploited.

Attacking end-to-end encryption in order to deal with the miniscule number of situations where law enforcement is stymied by encryption would, in actuality, put everyone at massive risk of having their data accessed by malicious parties. It's incredibly clueless and incredibly shortsighted.

And it's absolutely stunning that it's coming from the EU. After all, we keep hearing how the EU believes in "privacy" and "data protection" much more than the US.

The 900 pound primate in the room, that no one is acknowledging, is that this technology [Intel's SGX] was designed to not allow the operating system to have any control over what it is doing. In the mindset of kernel developers, the operating system is the absolute authority on security, so we find ourselves in a situation where the kernel needs to try and work around this fact so any solutions will be imperfect at best.

As I've noted before, this is actually a primary objective of enclave authors, since one of the desires for 'Confidential Computing' is to hide things like proprietary algorithms from the platform owners.

I think it is really important that we find a way to accept funding like this. I'm fine if we as a community have concerns about the specifics. But free software isn't supposed to mean developers don't get paid, or the software doesn't get funded (or even the software itself isn't expensive although given the user freedoms you are generally able to find someone to give you the source code cheaply). Also, Debian is at a disadvantage, because we are not able to effectively fund development in ways that other projects can.

On the other hand, this story about GtkPod is just one of many similar stories. Real problems have been solved in open source software, and computing historians, vintage computer enthusiasts, researchers etc. can still benefit from that software long into the future. Throwing out all this stuff in the name of "progress", could be misguided. I'm especially sad when I see the glee which people have expressed when ditching libraries like Qt4 from the archive. Some software will not be ported on to Qt5 (or Gtk3, Qt6, Gtk4, Qt7, etc., in perpetuity). Such software might be all of: unmaintained, "finished", and useful for some purpose (however niche), all at the same time.

All good stories need at least a villain so I have arbitrarily chosen copper thieves as the villains of the story that set in motion what youtube-dl is today.