Turtles all the way down: Hardware

So, let's get down to the nitty-gritty.



Let's lay one thing out first: At some point you're going to have to start trusting your toolchain because it simply won't be possible to accomplish some of the necessary tasks yourself. The lowest possible level sseems as good a place as any to start. I mean , the basic component of integrated circuitry. Let's face it, nobody's in a position to turn ordinary sand and handfuls of trace elements into silicon wafers themselves. This is a very complex operation that you can't do in your basement these days. There are lots of companies that and if you are in such a position by definition you're a central point of failure because you can do pretty much whatever you want to them and we can't tell (please see ).




Chip design these days is more like programming than electrical engineering. When chips were simpler a couple of decades ago (for certain values of 'simple') they were more like analogues of circuits based upon discrete components, just much smaller. Up until the Intel 80386 or therabouts (or so some of my more knowledgable colleagues tell me) they were still designed manually, and had blueprints that could cover the floor of a high school gymnasium or larger. Hardware description languages like , , and made it possible to define the myriad functions of microprocessors in much the same way as the software that runs on them. There are even simulators which allow chips specified in an HDL () to be compiled and executed in virtual environments for testing so that chips don't have to be fabbed to be debugged. The languages' compilers take the instructions and convert them into circuit diagrams and chip layouts which are used to fabricate the wafers.



It's certainly possible for hackers to use HDLs to develop their own chips. There are open source HDLs like Verilator Icarus Verilog which are fully usable for this purpose. There are websites like which are directories of IC specifications that you are free to download, read (and audit!), tinker around with, fabricate, and use yourself. There are even fully operational CPUs on those sites - 8-bit, 16-bit, 32-bit, and 64-bit. Some of them are re-implementations of classic microprocessors, like the 6502, M68k, OpenSPARC, OpenRISC, and OpenFire just to name a few. There are also open source CPUs like the which are not only fully operational microprocessors but also have their own software development toolchains. To put it another way, with a little patience you could download the designs for probably all of the chips you need, verify them (if you're of a mind to), modify them if you feel a need, and implement them somehow so you ca use them. My advice is to pick something that you can get real work done on every day. Go 64-bit if you can, but use a 32-bit core if you have to.



A sound question to ask is, how can you trust that your copy of the HDL source code for a core hasn't been tampered with? The answer is that you can't unless you wrote the whole thing yourself. There aren't any security measures approaching perfection unless you have absolute control of the entire development process starting from step 0. You'll have to accept some risks and mitigate other risks as best you can, because the alternative is to give up. Some of the ways to mitigate the risk are to check out copies of the code from multiple repositories around the Net (yay, distributed version control systems like and ) compare them to one another to see if they've been tampered with. This can be done with common tools like , , and . It's also possible to use the revision control tools to compare multiple checkouts of the same repository to make sure that they have the same states and the same commit histories. If n copies of the code from far and wide all match, chances are they haven't been tampered with. If they don't, then their will diverge after a certain point, which narrows down where you need to check for shenanagains. on downloads help verify this, too. You do check the signatures, right?



It's painful to admit (and a lot of sufficiently paranoid people are going to cry foul at this point), but at some point you're going to have to trust someone. In our case we need to have some amount of trust that other hackers who are working on bits and pieces of this project are not up to any skullduggery. I know, this runs totally counter to life in the grimdark cyberpunk future we live in, but we're all in this together. The alternatives are either teach yourselves how to design microprocessors pretty much from the ground up, or to abort the plan. The former is entirely possible - proof above by freely available practical implementation - but how much time do you have on your hands to do so?



So, time to sit down, figure out your use cases, and plan your project appropriately. What do you want to do with your trusted open system? Start picking out open cores that match those functions.



This work by The Doctor [412/724/301/703][ZS] is published under a .
Full Post