Feb 03 2014
This brings us along to designs that are rather common even though we don't normally think of them as either common or systems. By this, I refer to SoC's - Systems On A Chip. As the name implies, they are full (or nearly so) computers implemented as single mother-huge silicon chips (relatively speaking). On the die you'll find a CPU or microcontroller, supporting electronics for same, an MMU, and enough interfaces to do whatever you want, be it plug in a USB keyboard and mouse, an Ethernet adapter, or a simple USB-to-serial converter circuit. An excellent example of a SoC is the Broadcom BCM2835, which forms the nucleus of the ultra-cheap RaspberryPi, which has become one of the most popular hardware platforms for hackers since the Arduino due to its low cost and the fact that it runs Debian GNU/Linux right out of the box. You can do almost everything with a RasPi that you can with a full-sized laptop or desktop machine. To be sure it has less RAM (512 megs on the high-end rev.B) than we're used to these days, but it's quite sufficient for such tasks as word processing, browsing the web, building multimedia entertainment centers, emulating other computers, home and vehicular automation, near Earth orbit launches...
The RasPi's firmware, which we don't have the source code for is a sticking point of this platform. As has been mentioned previously, firmware blobs can potentially be doing anything and we wouldn't know unless the time was taken to reverse engineer them. The distributions of Linux and BSD that run on the RasPi seem to have a "whatever it takes" attitude toward getting the job done, and have incorporated code that loads the vendor-supplied firmware. This has caused several projects to flat out refuse to port their OSes to the RasPi.
Another example of a commercial SoC is the Vortex86DX2, which is a 32-bit x86-compatible CPU that also incorporates USB, SATA, PCIe, Ethernet, JTAG, and several other peripherals and interfaces on a single chip. It runs at 800MHz and consumes only a hair over 2 watts of power. The downside is that it's closed source commercial product so you can't audit what might be going on inside the chip. Once again, if you bounce over to OpenCores' System On Chip page (note: that link goes to the projects page because there's no way to link to a specific category) you'll find a collection of open source SoC's that you can flash onto appropriate FPGAs and run with. I would also like to mention that a few hackers have re-implemented entire computers on single FPGAs, from the CPUs all the way to the graphics controllers and audio chipsets. Case in point the Suska, a stem-to-stern reimplementation of the Atari ST on a single chip. In 2012 the Open Source Hardware User Group of London held a seminar on how to implement an OpenRISC SoC on a £50 FPGA board, which demonstrates that doing so is entirely feasible for an emminently reasonable cost. There is also the ORPSoC (OpenRISC Reference Platform System on Chip), which combines an OpenRISC OR1200 CPU with a set of peripherals. A potential risk to the project is incurred in the the FPGAs themselves; some of the more powerful units have lots of processing power on board that could potentially have been subverted somewhere along the line. Caveat hacker.
The trusted and open computer we are hypothesizing is going to need some peripherals so we can interact with it. At a minimum, we need a display, a keyboard, probably a mouse, and storage (volatile and not). If you are able to build your own high-res display comparable to those commercially available these days, please post your instructions so I can mirror them. So far as I know at this moment in time, constructing a display from scratch is probably not feasible. Using a different kind of display, like an older television with an RF modulator is possible but you might not get very high resolution graphics out of it. Even the RasPi's composite video output tops out at 720x576 (on a PAL television), though its HDMI output is considerably better. People like graphics. Going the text-only via serial terminal route is possible but, let's face it, nobody's going to do it. Depending on how hardcore one is, repurposing displays that are sufficiently simple that the circuitry can be eyeballed to determine that it was probably not tampered with is a possibility. Salvaged laptop display panels, for example. However, just to get this show on the road we're going to use a commodity video display, USB keyboard and mouse. We're going to assume that you've located suitable physical RAM for the SoC or CPU that you've selected for the core of the trusted open computing stack. We'll need a graphics chipset of some kind to make this happen; our options range from high-res LCD controller to VGA display adapter to sourcing a discrete graphics chipset and intgrating it into our board.
Another option would be to run our open and trusted system headless, SSH into it, and access applications running on our platform either inside the context of an Xvfb pseudo-display or export the X windows over SSH. We could configure everything as we install the OS to the open and trusted computing platform before booting it if we had to. We would have to produce a USB v2.0 chip to be able to make use of our interfaces. It might be worth our while to investigate an open source I/O controller, which could interface the storage subsystem with the CPU, USB chipset, and whatever other I/O controllers wee added. Then again this is also a strongly x86 PC conceit and there are other potential hardware configurations, some of which might be simpler and use fewer FPGAs (which would reduce both complexity and cost). I'll definitely have to give this some more thought.
What about storage? Hard drives or flash media. Can we make them ourselves right now? Probably not. Hard drives we certainly can't manufacture because we don't have clean rooms or the gear to manufacture hard drive platters, so we'll have to source drives from someplace. Except that we know some of their supporting chips are potentially backdoorable before they get into our custody. We might be able to get away with using flash media like SD cards (I do on my netbook), but flash media has embedded microcontrollers that are hackable, too, and they can potentially be compromised before they get into our custody as well. At this point I think it's safe to say that there are always going to be potential points of external compromise, and short of a post-scarcity microfacture facility there isn't a whole lot that we can realistically do except try to estimate how much risk we're accepting by sourcing certain complex components on the open market. Were I in this position I'd use the same strategy outlined in the FPGA post and try to present as small a moving target evidencing as little of a predictable pattern as possible. Good luck.
We'll need an interface controller for whichever storage we go with. There are implementations of IDE and SCSI floating around. I've heard of one or two open source SATA chipset designs floating around but haven't actually tried any of them. It seems reasonable to me that reading up on software emulations of storage controllers, such as those in VirtualBox's source code would be somewhat enlightening at least. Same with CompactFlash or SD card interface controllers. We'll need a USB chipset as well, and there are implementations of that which can be had (unless we opt for getting our hands on a small batch of them on the open market, or if we salvage a few from old mainboards which we can acquire documentation and pinouts for). We might want to consider getting hold of some after-market USB boards and integrating them (but then we're running a significant risk of compromise there - there's no way of knowing what's really in those chips, is there?)
Are there other means of mass data storage that we can use? Certainly. They're probably too slow to be practical these days, though. Magnetic tapes and floppy disks are still around. Kind of. You'll have to really hunt for them, and probably buy and clear used ones from the surplus market to get hold of a supply. Tapes are extremely slow and floppy disks are even slower. It seems reasonable to state that trading off some processor speed for peace of mind might be okay, but 1980's data transfer speeds are unacceptible. Optical disks can't be used for read/write storage in the same way that a hard drive or solid state media can. So, hard drives or flash media with an appropriate file system (like YafFS, BTRFS, or EXT4) should be sufficient. Of course, you'll want to encrypt your storage media to protect the data in case somebody tried to copy while you were out and about...
Another question which seems reasonable to ask is, can we go to the trouble of building our own mice and keyboards? The answer is "probably." In the recent past people have done so for special purposes. It's possible if you have the equipment to fabricate the necessary physical parts (like a 3D printer), or access to such equipment. It might not be worth doing so when compared to how much trouble is involved because we're discussing building a mainboard and chipset from as far down the stack as possible. We do want to finish this project in a somewhat reasonable period of time given the overall difficulty of the effort. Then again it would be interesting exercise (if only because Kinesis keyboards are stupidly expensive). The amount of effort that would go into developing the microcontroller for a custom keyboard or mouse seems as if it would be miniscule when compared to the effort that would go into constructing ICs and a mainboard.
This work by The Doctor [412/724/301/703][ZS] is published under a Creative Commons By Attribution / Noncommercial / Share Alike v3.0 License.