Are there any open, vetted computer system out there?
How do projects such as the Raspberry Pi fare in terms of security?
Are there any open, vetted computer system out there?
How do projects such as the Raspberry Pi fare in terms of security?
The CPU on that isn't the first thing that boots. There's a binary blob that boots the GPU first, and gets it to boot the CPU.
There is some progress on being able to boot without the mystery code, but it's not complete: https://hackaday.com/2017/01/14/blob-less-raspberry-pi-linux...
Broadcom offers very little documentation. I don't think an RPi would be a good security choice.
A Beaglebone Black has a better documented CPU and boot process, and can run stock, non custom Linux. Not specifically "secure", per se, but is at least easier to research. Can't vouch for it, but here's an attempt to make the BBB a secure environment: https://cryptotronix.com/products/cryptocape/
Define your limits.
For the everyday, you won't get far. Intel, AMD and others have all been shown to have problems like this, or at least things they specify for government agencies.
However, tiny computer architectures like MIPS, AVR and the like probably don't, simply because they tend to be too small. They don't have the memory for advanced backdoor techniques... But are trivial to access their memory if you have physical access.
Straight-up RISC-V is too new to truly trust security, but looks fairly great... Until you realise that almost everyone is going to add their own proprietary extensions to it, and those extensions may well include things like VISA.
---
The Raspberry Pi uses a Broadcom ARM chip. (Which model you get does have different models of the particular SoC, and the two main chips are vastly different).
I don't have enough details about the particular chip to tell, but ARM does have it's own remote management system. It may or may not be part of what Broadcom offers, and may or may not have undisclosed abilities to offer to clandestine agencies.
Bad analogy because Risc-V is an instruction set, not a physical microarchitecture. Back doors and side channel attacks could still be possible when implementing risc-v as a uarch.
The same applies for any ISA be it MIPS, x86-64, Power, Arm, Spark, PA Risc, Alpha, etc. They're just different programming languages implemented in hardware. And like software, hardware can have bugs too, though patching is much harder or impossible.
What do you think are the reasons that a "safe-by-default" CPU design has not yet seen the light of day?
I could go back to really old systems, but it does not make really sense to use the 'security through obfuscation' strategy, no?
Tradeoffs, and motivations, really.
This is going into the land of speculation and opinion, but I think that we did see some more secure CPUs in the past. I also expect that the military and some industries may have access to more secure versions of CPUs currently on the market.
Being more performant became one priority, which lead to do unsafe things that allowed Spectre and others to become possible.
And on the other hand, the more diverse and prolific technology becomes, the more interested in being able to access it in a surreptitious manner the government is. Many modern governments seem obsessed with getting as much data as they can - so much they can't even read it all.
So on one hand you have pressure from consumers to improve speed at any cost, and on the other you have state actors pressuring to keep the status quo of semi-leaky hardware.
I have no idea what kind of error checking procedure the CPU industry uses, but it is hard to believe that Intel et al. do not use highly integrated proof tools that cover multiple design layers. I know that these are very complex systems, that you can't cover certain cases with proof tools, and cost might be a factor at play - but I believe that there is interest in private and public markets to get hands on a stack that starts with a higher security threshold compared with what we have now.
There's certainly some interest, in some parts of industry.
NASA [0] has an FPGA board they made to be more rugged, for CubeSats, which had multiple layers for preventing program corruption. I'd be shocked if it had a backdoor into it, and would expect parts of the system would make it more resistant to tampering.
Unfortunately, I also expect that if any chip becomes something popular among consumers, state actors will push their weight and get their weaknesses.
[0] https://www.nasa.gov/mission_pages/station/research/experime...
1. Take an Intel or AMD system and try to secure-ify it. This is what vendors like system76[1] and Purism[2] do, especially aided by the coreboot project[3]. I'm not an expert on the details, but an important goal in this space has been disabling Intel ME[4], which I note in the original parent article seems to be part of this exploit (at least when used remotely). AMD has a corresponding parasite cpu-in-cpu, not sure about progress on disabling.
2. Use another CPU. Someone else mentioned the raptor project, that's all I know of (but again I'm not an expert). But by far the most common consumer CPU that competes with Intel and AMD, who make x86 processors, is the ARM platform used by phones, Raspberry Pis, and many embedded devices.
Note the CPU is only one kind of closed firmware that can have backdoors or insecurities....
[2] https://puri.sm/
The PlayStation 4 has an x86 chip, but is not a PC. It cannot boot a mainline kernel because a lot of basic assumptions about how a PC works don't exist on the PS4 platform. The Fail0ver people have done some great talks at all the issues porting Linux to the PS4.
The trouble with ARM is that it's not an architecture. Linux got so popular among developers and nerds in the 90s because you could just install it on any PC that was out there. When people got hardware working, they could upstream their changes. Phone manufactures patch the hell out of their kernels in terrible ways that can never be up-streamed, and include tons of binary blobs and shims. PostmarketOS is making some progress here, but it's slow.
ARM phones don't have a standard BIOS. (with the exception of the Windows Mobile line, which has ARM+UEFI, yet Microsoft still won't release a bootloader unlock even though their phone is pretty much dead at this point). Some ARM devices use the devicetree standard for hardware identification/allocation, but it's still a mess.
I wrote about this before:
Indeed, the control and understanding of the CPU (and auxiliary chips) is key.
A naive question: what are the resources needed to get your own CPU architecture going, not necessarily state of the art, but older technology?
The fabrication technology is there, after all. And many a patent should be expired by now. Also, there must be some academic projects out there which build such complex systems.
They have a powerpc based desktop system where every component has its firmware open and available.
(No comment.)
Used OpenCompute enterprise server from eBay, with LinuxBoot as BIOS.
Future: OpenCompute platform based on OpenPower CPU, Open System Firmware and an open-hardware implementation of Microsoft Cerberus / Google OpenTitan.
https://store.vikings.net/libre-friendly-hardware/the-server...
How far along are these Open Architecture Systems?
An alternative to me_cleaner on some systems (like ThinkPad X200) is to replace the BIOS entirely with Coreboot [1]. More recently, it was found that me_cleaner appears to let you remove/disable all or part of Intel ME on those and some other architectures but still boot.
[1] My own notes from when I played with this, which was a mixed success (it was way too much headache to have a huge number of people each do): https://www.neilvandyke.org/coreboot/
Raptor Talos II comes to mind. Quite powerful, and fully auditable firmware. Uses an IBM POWER9 cpu, no x86
You will pay dearly in cost, performance and pretty much every other metric that you care about though.