> Perhaps I am looking for something like the x286 DOS computer I had in the early 1990's
You can do an almost fully GPL compliant Linux desktop by building it yourself today. I can already see people thinking "but what about the closed source binary blobs? my video card? my network interfaces?"
But even your 12 MHz 286 or 386SX/20 had closed source AMI or Phoenix BIOS firmware on it. The motherboard manufacturer in Taiwan and American Megatrends sure weren't handing out the source code to that. And if you had a video card, or a soundblaster, its drivers loaded in config.sys were also closed binary blobs.
While the BIOS and VBIOS of a typical 286/386 machine was indeed a closed-source binary blob, there were several factors that helped keep this in check:
1. The underlying hardware interfaces (I/O ports, memory addresses, etc.) was considered part of the IBM PC "standard" and many programs would bypass the BIOS and talk directly to the hardware.
2. The software interface to the BIOS and VBIOS was also part of the IBM PC "standard", and so the firmware couldn't diverge too far from the expected behaviour without risking compatibility issues.
3. Once the PC entered protected mode, the BIOS essentially turns into a useless brick, and ceases to have any influence on the operation of the CPU. (That is, once in protected mode, the OS kernel in ring 0 had full control of the system, and none of the BIOS code remained active.)
The difference with modern systems is stark: binary blobs often provide the only means to operate the hardware devices, CPUs have special execution modes (such as SMM) which continue to execute binary firmware even after the OS has booted, and even the CPU itself holds binary blobs (such as microcode patches).
You have (almost?) no way to verify how the transistors inside the computer chips are wired. And even if you design your own chips, you can't really know if the design you specified has been faithfully followed at the fab facility. It's a tough problem.
The question then, really, is how far are you willing to go down the stack of software on hardware, in pursuit of true ideological purity? How can, even the Pinephone manufacturers, be absolutely sure that their design is being implemented in hardware as they specced it, without backdoors?
If you have a near infinite amount of money and resources, you can be absolutely certain (the hardware that runs NSA approved type 1 crypto goes through a very thorough vetting process), but such a concept is economically unrealistic for anything that normal people can buy.
Hardware level trust would be really cool. It seems theoretically possible because all you need is an accurate measurement of some physical property that is hard to forge when changing transistors orders etc. Practically though, anything like that would be most likely affected by manufacturing tolerances for the transistors, so you’d have to find something that allows a certain amount of error when individual transistors change, but will reveal unknown transistors and connections.
Even if this was achieved, the rabbithole would continue though, because the thing you measure with could now have a backdoor. Remind me of the classic paper about the same problem with software: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
As the paper points out, ultimately you have to trust the people. This is why vetting processes exist for access to some critical things. And why I have a fairly high degree of confidence that certain reputable people can be relied upon to take a firm stand on principles and ideology (example: if somebody was trying to pressure Moxie Marlinspike to backdoor Signal).
Definitely, but in the pre 1995 time frame for both MS/DOS and Unix derived workstation stuff, the default was for everything to be closed source and proprietary. Vendor lock in for high performance systems was much greater than the open hardware platforms and interoperable things we can piece together today.
If you had a time machine and gave some developers in 1991 the massive cpu, ram, storage and bus i/o throughput that we have today in a $1200 desktop PC, I don't doubt that they would have made those binary blobs a lot bigger and more complicated. Something about the typical software environment expanding to fill all available resources, seemingly as an inevitability.
There was no management engine, no "phone home" functionality. And those drivers you mention were often handwritten assembly to the point that reading the disassembly would be as good as having the source code.
In the olden days of real mode MS-DOS, if you want to gather keystrokes from the user securely (e.g. a password) the program could simply take over the IRQ1 (keyboard interrupt) vector and that was sufficient. The extra paranoid could also revector the other interrupts (or disable interrupts entirely) and ensure they had exclusive control of the entire machine.
You can do an almost fully GPL compliant Linux desktop by building it yourself today. I can already see people thinking "but what about the closed source binary blobs? my video card? my network interfaces?"
But even your 12 MHz 286 or 386SX/20 had closed source AMI or Phoenix BIOS firmware on it. The motherboard manufacturer in Taiwan and American Megatrends sure weren't handing out the source code to that. And if you had a video card, or a soundblaster, its drivers loaded in config.sys were also closed binary blobs.