IF your biggest risk is someone will find out you dye your hair or are a biker who actually likes Opera and Ballet when not doing the weekend warrior thing, you don’t really care about this level of security.
IF you are worried about the PRISM program compromising equipment makers and embedding spy facilities so that the government of the USA can suck in every drop of information from everywhere, then you DO care.
Since I’ve been employed for “Industrial Strength” computer security in many companies over the decades, I care.
With that preamble:
It seems that Intel and AMD have decided to put a “computer inside your computer” that only they know how to operate, doing only what they tell it to do, and where nobody but them can see the programs running in it. IMHO, this is a security hole you could drive an entire Three Letter Agency through.
But worse, us “Hacker Types” being very cleaver folks, have figured out how to exploit it… Which means other Governments around the world will also know how to exploit it… Which means you are at risk for Chinese, Russian, Iranian, and who knows what all else TLA’s crawling into your Intel or AMD run box and doing it in such a way that you can not see them, nor ferret them out. Since ARM chips are not subject to this class of exploit, that’s why I’m so focused on making my home systems out of them.
The Nature of Exploits
This is from 2008, so not exactly new. But as a Linux user, I’ve often lived on antiquated equipment (as it is more than fast enough for Linux) so didn’t care too much. Work, over the last decade+, has had those decisions made by others so “not my problem” at work sites. Now I”m needing upgrades to some of the gear I’ve lived on for years. What to do? Well, I chose to dodge the whole issue by building my world on ARM chips. They (so far) are not fundamentally buggered like Intel and AMD chips. Furthermore, for the years post 2008 up to about 2014, I’d selected AMD chips that were less of an issue… until about 2014.
What’s the issue? How about a little hardware CPU built on the side of your big Intel Architecture CPU with full privileges to get into all files, inspect all network traffic, and running software you can not see, audit, change, or control? Think that might be an issue?
This article talks about a different exploit (“Blue Pill” and SMM attacks) but illustrates the nature of computer cracking / hacking in the modern age:
Hackers Find a New Place to Hide Rootkits
By Robert McMillan
IDG News Service | MAY 9, 2008 2:00 PM PT
Security researchers have developed a new type of malicious rootkit software that hides itself in an obscure part of a computer’s microprocessor, hidden from current antivirus products.
Called a System Management Mode (SMM) rootkit, the software runs in a protected part of a computer’s memory that can be locked and rendered invisible to the operating system, but which can give attackers a picture of what’s happening in a computer’s memory.
The SMM rootkit comes with keylogging and communications software and could be used to steal sensitive information from a victim’s computer. It was built by Shawn Embleton and Sherri Sparks, who run an Oviedo, Florida, security company called Clear Hat Consulting.
The proof-of-concept software will be demonstrated publicly for the first time at the Black Hat security conference in Las Vegas this August.
For example, two years ago researcher Joanna Rutkowska introduced a rootkit called Blue Pill, which used AMD’s chip-level virtualization technology to hide itself. She said the technology could eventually be used to create “100 percent undetectable malware.”
“Rootkits are going more and more toward the hardware,” said Sparks, who wrote another rootkit three years ago called Shadow Walker. “The deeper into the system you go, the more power you have and the harder it is to detect you.”
In many ways, an SMM rootkit, running in a locked part of memory, would be more difficult to detect than Blue Pill, said John Heasman, director of research with NGS Software, a security consulting firm. “An SMM rootkit has major ramifications for things like [antivirus software products],” he said. “They will be blind to it.”
Researchers have suspected for several years that malicious software could be written to run in SMM. In 2006, researcher Loic Duflot demonstrated how SMM malware would work. “Duflot wrote a small SMM handler that compromised the security model of the OS,” Embleton said. “We took the idea further by writing a more complex SMM handler that incorporated rootkit-like techniques.”
Now those hacks exploit particular aspects of the Intel hardware that are in common use and have been for a very long time, but they are an example of how hacking / cracking works down at the bit twiddle level. You work just on top of the hardware, bypassing the OS and protections, and try not to be found doing it.
Now, think it would be of benefit to have a completely separate processor you could hack on that was by design hidden from the owner’s view?
Folks who’ve been reading here a while know I’ve railed against changes to the boot loader such that it has control of too much but let you have control of too little. For that reason, I don’t buy UEFI boot loader machines if at all possible, preferring “coreboot” as it is under “owner control” and the source code is public. Well, some folks are even more paranoid ( i.e. have more deep experience…) than me. They find the tendency for coreboot to allow “binary blobs” to be included to be just asking for someone to put a Trojan or backdoor into the blob. I like folks like that. They write a tighter boot loader called “Libreboot” (as in freedom).
Quoted in full so you can get a sense of all of it. Please do hit the site for even more on some deeper and less problematic, but still problematic, issues with Intel and AMD. Note that the #tags are live links in the original. Bold added by me:
Why is the latest Intel hardware unsupported in libreboot? #intel
It is extremely unlikely that any post-2008 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible. The main issues are as follows:
Intel Management Engine (ME) #intelme
Introduced in June 2006 in Intel’s 965 Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G)MCHs, and the ICH8 I/O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G)MCH chip. In Q3 2009, the first generation of Intel Core i3/i5/i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME (now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid 2006.
The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has network access with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key, which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.
The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.
The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL/TLS libraries, but recall that all of the major SSL/TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities, which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.
Intel Boot Guard is an ME application introduced in Q2 2013 with ME firmware version 9.0 on 4th Generation Intel Core i3/i5/i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.
ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for audio and video DRM called “Protected Audio Video Path” (PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen.
The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored.
Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.
Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”.
In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.
More information about the Management Engine can be found on various Web sites, including me.bios.io, unhuffme, coreboot wiki, and Wikipedia. The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.
If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Also see (effort to disable the ME): https://www.coreboot.org/pipermail/coreboot/2016-November/082331.html – look at the whole thread
Firmware Support Package (FSP) #fsp
On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles all of the hardware initialization, including memory and CPU initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes this blob to firmware developers, without source.
Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).
All this to make the “media” vendors happy with some kind of restrictive and enforceable anti-copy facilities…
Up until a few years back, you could dodge this by using AMD CPU chips. No longer:
Why is the latest AMD hardware unsupported in libreboot? #amd
It is extremely unlikely that any post-2013 AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible. The main issues are as follows:
AMD Platform Security Processor (PSP) #amdpsp
This is basically AMD’s own version of the Intel Management Engine. It has all of the same basic security and freedom issues, although the implementation is wildly different.
The Platform Security Processor (PSP) is built in on all Family 16h + systems (basically anything post-2013), and controls the main x86 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x86 cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI/PCIe peripherals installed on the system.
In theory any malicious entity with access to the AMD signing key would be able to install persistent malware that could not be eradicated without an external flasher and a known good PSP image. Furthermore, multiple security vulnerabilities have been demonstrated in AMD firmware in the past, and there is every reason to assume one or more zero day vulnerabilities are lurking in the PSP firmware. Given the extreme privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities would have the ability to remotely monitor and control any PSP enabled machine. completely outside of the user’s knowledge.
Much like with the Intel Boot Guard (an application of the Intel Management Engine), AMD’s PSP can also act as a tyrant by checking signatures on any boot firmware that you flash, making replacement boot firmware (e.g. libreboot, coreboot) impossible on some boards. Early anecdotal reports indicate that AMD’s boot guard counterpart will be used on most OEM hardware, disabled only on so-called “enthusiast” CPUs.
Libreboot had been a part of GNU, then there were some internal fights and it split out as a distinct project. On the Libreboot web site you will find a lot of documentation of this, all of it emotional. (It involves Trans folk being outed and management being a pill about it). Please don’t let that color your thinking. In my experience managing programmers, the best ones are often a bit “bent” in some way. Many are gay or trans, a bunch are more Aspe like, etc. etc. Something about that “outsider” context seems to make for really good coders, if sometimes they can be an emotional handful to manage. (One of the best ones I ever managed had orange dyed hair in a peak, also on the team was his ‘frienemy’, a cute girl with attitude and with Purple Hair where at various times they would fight like Nazis vs Stalin and at others be sleeping with each other… made for interesting dynamics and odd HR discussions… “Please just leave it be for a week and it will change”)… Just realize that kind of thing does NOT impugn the technical quality of the work, and can be a flag of extreme diligence in programming.
So that’s why I’m building all my home systems out of ARM chip based devices. Why I use Intel / AMD boxes only for things that have no significant security risks. Why I’m interested in “home cluster computing” with a stack of cheap ARM boards and NOT interested in buying a big high end PC with Widowz, UEFI, Intel Inside and more…
IMHO it is a direct result of USA TLA’s influencing vendors at all levels (PRISM program) to bugger their products for “easy access”… and blended with the Media Industry demanding they have control of how your computer operates. The latter providing great cover for the former.
Note that the Router and Embedded Systems guys generally work on small lot system boards and demand bit level security (unless, like Cisco, big enough to be PRISM influenced by Government contracts & leverage…) so need things like Coreboot / Libreboot – thus the lack of buggerage at that level.
I depend heavily on those folks demanding to see the source code and on folks like the Libreboot team to find and expose the buggerage. (No offense intended to buggers and “backdoor” folks… just not something I want in my computers…) It is well worth it to find, and follow, the blogs and web sites of such folks. Also the Vegas Black Hat conferences “out” a lot of interesting things. (Why my TV has no internet connection and why I will NOT have an I[di]OT home…)
FWIW, another useful indicator is the OpenBSD folks. They often refuse to port to boards where they think they can not prove a secure boot (i.e. without non-vendor binary blobs). That doesn’t filter for this class of exposure (to a potentially compromised vendor leaned on by Government) but does find a lot of others. For example, they don’t like the way that the Raspberry Pi uses a “binary blob” to load the OS and run the GPU. I’m OK with that (for now) as it is highly unlikely to be an issue, but “someday” might move to systems like Odroid with coreboot like boot loaders if the “binary blob” has any indications of being big enough to be an issue. Oh, and there are some efforts underway to make an open source version of the binary blob bootloader, so that issue may go away over time.
And that is why I look at things like boot loaders and chipsets and low level features in CPU chips.
IMHO, there is a BIG market for a non-USA maker to fab up a demonstrably clean CISC CPU with open source microcode and Libreboot boot loader. I know I’d buy a half dozen of them… ARM is slowly migrating from a RISC chip to CISC, so may become that over time. They already match the low end Intel CPUs on performance. I’d like to have other options available, though, just in case some government or other leans on them, too. MIPS and PowerPC are chip sets I likely ought to look at, but there’s only so much time for that kind of thing and they have been out of favor lately. In any case, nobody seems to be advertising those security features / issues…
So in the future it all may be different, but for now I’m using ARM as the preferred secure platform, and now you know why.
So, I googled “ARM motherboard” and see there are some on line. Is the simple fact it is ARM enough to know it has no UEFI boot loader and no “security” mini-processor?
Thanks for the post, I had no idea these mini-processors existed and have been contemplating a new computer. I usually put them together myself.
after talking to my grandson about this, he is on top of it. careful about the chips he is using in our Intel base boxes. this will cause a drop dead point where unkugged chips will be too out dated to be useful. good thing he bought a bunch of the highest ability chips made just before the change over…pg
Wow that is disturbing, side observation here:
Can someone running snoop on the network connection discover the ME MAC address?
If so, you could then at least black list that MAC from communication out bound on the network and redirect traffic heading inbound to that MAC at the firewall correct?
It’s a shame the PowerPC architecture didn’t gain more traction in mind share and market share.
A pretty strong favorite in the embedded world
It seems the MAC address could be found with something like Wireshark.
Also, given this hidden system, I guess running an OS like TAILS wouldn’t guarantee privacy?
The Raspberry Pi and Odroid (and really all the “Fruit-Pi” class) are ARM boards. That’s why I’m doing all these postings about how to set one (or a few…) of them up as your infrastructure and desktop…
You can buy bigger and more expensive systems, if desired. A very good thing is to find those with “coreboot” boot loader listed. The Chromebooks, as laptops, have some made that way (though others are Intel chipsets …)
FWIW, the list of “supported hardware” at Libreboot is a pretty good list of “more secure than most folks will ever need” hardware.
Per Tails; Yup. Keyloggers don’t need to deal with decryption nor do screen scrapers.
Again, unless you are a spook or a drug dealer, you are likely OK with “the usual security” and having your pants subject to being pulled down by a Government TLA. I’m using an Intel Mac at the moment (the “dead” one now running from a very slow SD card…) and would not mind at all using a Windoz box to read WUWT. For banking, I boot a dedicated chip in ARM hardware… so it has zero risk of being infected by random web sites… (and have a binary copy archived for any needed ‘re-flashing’ the OS Chip…)
Prior to the spousal MacBook “dying” (and my inheriting it …) I’d planned to buy a Chromebook with ARM chip in it and coreboot. “Good enough” as a daily driver web browser and email platform. Do realize you need to replace Chrome O/S with Linux to avoid Google sucking up all your data and never use a cloud service is you want privacy… Set up a Pi board running “Owncloud” if you want cloud storage…
One hopes so, but it might mutate the MAC if no contact can be made and it also can only be seen when it speaks, so when exactly is that?….
Now on my “someday” list is to ‘roll my own’ interior router that ONLY lets out TCP traffic (block all UDP) and ONLY from known and locked MAC addresses / IP numbers. Basically lock things to ONLY the CPU / interfaces I know and approve. Haven’t done it yet due to low real need so far (in that I’m fairly paranoid / locked down / careful already…)
Got a reference for an embedded board you like? I’d not mind at all bringing up a higher end Power PC processor on an embedded board as a desktop. Heck, IF I like it enough, I could even offer pre-built ones for folks “of my Ilk”…
I just don’t have the time to sort though the thousands of embedded boards out there and pick one..
Well above my paygrade (which is subzero) so I will drag Hubby, kicking and screaming over to read this.
The short form is that any new Advanced Micro Devices CPUs or Intel since about 2008 open big new security attack surfaces and exploits are starting to who up “in the wild” while The US Government has a high probability of being a built in exploit from the get-go.
This attack surface is a little computer built inside the CPU chip that you can’t see, control, audit, clean, manage, or stop from buggering you. You MUST trust the vendor and their government relations group for any security…
For typical home users, you only care a little (as most of the exploits so far are more academic than actual flag captures in the wild) but ought to care more over time.
For folks with serious security needs (i.e. not just email about your hair color but records of your infiltration of a local Jihadi Group and how your Russian Handler appreciates it) you ought to immediately consign any Intel / AMD systems to “Lite Use” browsing how to make cookies and reading up on the local church services to attend, and use a Raspberry Pi or similar with a security oriented build on it for more “private” things.
No, not a drug dealer or anything like that. Just on principle, want my privacy. And your point about the bank and other financial web sites is a good one.
I’ve been watching the TV show, Hunted. Facebook it a huge liability if you are on the run. And there are so many CCTVs around, drones, cell phone towers, you name it. Good show, though.
To bad *nix accessibility is still so awful, especially when using text-to-speech rather than braille (I do not use braille). From talking with folks who use macs Voice Over is okay if all you need is browsing/email but XCode for example is a terrible experience.
With a third party screen reader Windows accessibility is for the most part now quite good (the things that aren’t wouldn’t be any better on a different platform because they are web apps that simply aren’t accessible to begin with). The built-in Narrator is about equivalent to Apple’s Voice Over, good for browsing/email and not much more. The third party screen readers run the gamut from free to $800 (plus a non-required but good idea $100/year subscription). That latter is the route I’ve gone, after ten years the amortized cost is now about 50 cents a day, a cost I consider more than worth it given the alternatives.
Given that I require more than browsing and email I don’t see giving up Intel or windows any time soon, regardless of what I might want.
This is essentially hosting a Parasite, in one’s insides.
The first thought is like unto what the Insect World is full of….
That brought to mind what Robert A Heinlein created in his classic “The Puppet Masters.”
I humbly suggest we henceforth refer to these parasitized systems as “hagridden,” as they could make the titular Users do things they had no intention of doing!
“… middle of the summer, and all the swimming pools are closed. Something odd is going on…”
The last x86 processors without ME or PSP are the Piledriver Opterons and FX processors, and the Steamroller APUs and Athlons. Thankfully these are readily available new for the time being, and quite cheap with the impending release of Ryzen chips. Get hold of them while you can, I’ve just built myself an Opteron 4332 HE workstation.
You are mistaken about the security of “ARM”.
Can you spell “microcode based rootkit”?
I don’t know if it is “mistaken” so much as “only other real alternative” and “good enough for now”.
The microcode is BSD based, so fundamentally sound and secure. No more exposed than most fairly secure things. Yes, one must “hope” there isn’t a back door in it, but that is always the case.
I am waiting for a Linux on a clean open source CPU, but it doesn’t exist yet. Oh Well.
Most other CPUs are just not strong enough to run a current desktop, or are similarly closed systems with no idea what is going on. But if you have a better chipset, feel free to say so.
If nothing better is offered, I’ll assume you are just griping and not contributing to a solution…
Very well written article that touches on all the major flaws of recent x86 platforms. I must ask though, why are you ok with the Pi’s relatively large binary blob required for booting? It seems like that would be a great target for a government agency (think GCHQ) to compel the UK-based Raspberry Pi foundation to insert a backdoor. They’ve already passed a lot of anti-encryption and pro-spying legislation, so this sort of scenario doesn’t seem too implausible.
I’m only tepidly accepting of the Binary Blob. My reasons are simple.
I don’t need TLA proof security in my home and toys. IF I did, I’d get one of the boards using open source bootloaders and put up with the more limited OS choices to play with and greater difficulty to make it go. I would only be using BSD , and likely only Open BSD at that, built from pristine sources.
Since I’m mostly just playing, and using downloaded binary OS images anyway, my greatest exposure is to a Man In The Middle interception of my whole OS installation. I trust the Pi folks to have a reasonably clean bootloader image, and Broadcom to not be really compromising a weak and irrelevant chipset (since it isn’t interesting to the TLSs) and figure somewhere someone will likely dissasemble and inspect it anyway… so until I’m building BSD from sources and worried about TLAs going after Pi hobbiests, it just isn’t a real risk.
But again: If your liberty or life depend on it, ONLY use a verified open source bootloader built from sources and run BSD built from verified sources. Oh, and be a competant systems programmer…
Or you can build your own limited run hardware?
Only problem with custom HW is writing the custom firmware and software…
OTOH, using a custom build of a known supported open source chip eliminates that…
OPEN SPARC based 25 core design…. Hey, if you would do all the work for a DIY build, might as well get some performance… It scales to thousands of CPUs if needed…
I hope Inever need to “go there”; but IFF neeeded, an Open SPARC box with a couple of dozen cores runnung BSD would be a Very Nice workstation…. would need care in the device driver area to avoid custom drivers, but not too hard…
Oh, and if you want a roll your own Right Now:
FPGA based Cpu Build with bitsream to config the FPGA and dowloadable OS *nix about $50 for the FPGA…
No idea on performance or SW / OS richness of build. But it is ready to roll (…your own…)
Would be fun if I had any time to play with it… but end to end you can inspect and tighten all aspects of HW & SW.