Code is Law, Hardware is Code's Language


The Law of Law is language. If your language is richly metaphorical and contains the word "schadenfreude", you will annex the Sudetenland, exterminate most of your ethnic minorities, and a surviving ethnic outlier will use your language to express general relativity. Other languages better express other crimes and concepts. A linguist will tell you all languages can express all concepts - languages are Turing complete - but this fashionable conceit does not tell us why different cultures do different things.

Code is law. Hardware is the language and law of code. Code can only do what hardware permits. A Turing complete machine can manufacture any set of symbols from any other set, but those symbols cannot go where the hardware doesn't connect.

In 1990 I designed a chip, a non-blocking crossbar routing device, for the startup I-Cube Design Systems. This chip routed signals from any pin to any other pin, and could route 240 inputs to any combination of 240 other outputs. But it also had fanout - it could route an input to two or more outputs. 160 inputs could become 320 outputs. This was useful for the original task - hardware logic simulation. When the original logic simulator customers became enmired in patent lawsuits, I-Cube found a new customer, another small startup called Cisco. Cisco's routers distributed the backbone of the early internet, and still route most of it.

I realize, decades later, that I made one of the architectural decisions that allows the NSA to watch you as you read this webpage.

Cisco's routers flowed bitstreams, not "packets", a software metaphor for a time-bounded sequence of bits. Packet headers told the router which flow got the bits, the router told the crossbar device which path the bits should take. Sending the bits to more than one place was implicit in how the hardware worked, because the hardware had fanout.

Cisco remains, I-Cube was killed by incompetent venture capitalists. I'm not party to how Cisco designs routers today, but fanout is implicit in dataflow, hardware can stream one transmitter to multiple receivers, tracelessly.

Software is merely "judicial opinion" applied to that hardware, and we non-electrical macroscopic human beings only have opinions, not sure knowledge, about how the bits are actually moving and transforming from memory location to other (possibly multiple) memory locations.

Software can encrypt - or it can pretend to. Software becomes machine instructions via a compiler. Dennis Ritchie taught us that a compiler emits machine instructions chosen by the compiler author, who can override the decisions of the source code author. The hardware author can override both. The hard disk manufacturer decides what firmware bytes go on the boot tracks of your hard drive, the disk firmware decides what bytes you actually get to your RAM from which disk track, and this firmware is invisible to the machine code it dispenses. In an age of Viterbi coding and VLSI disk chips, even a hardware logic analyzer may not tell you what's actually on the boot tracks. For sure knowledge, you will need your own hardware, either your own replacement disk chips or a focused ion beam milling system (FIB) to take apart the disk chips and learn what they actually do.

The economics of chip production make it impossibly expensive to give everyone a different chip architecture, though you can cheaply individualize every chip (another of my inventions, see ). If there is a ghost in the hardware machine, it is in all the machines, and those versed in VLSI, equipped with FIB, can find the ghosts. The individuality can be perfectly hidden, and cannot be unmasked without destroying the chip.

Puzzling out a proprietary design is possible but time-consuming, perhaps costing as much as the original design. Verifying that an open source hardware design is faithfully replicated in silicon is relatively easy, and could be automated, perhaps as cheap as sequencing a genome. We do not do so, because software designers pretend the substrate does not exist, or is logically identical to all other substrates, and thus not worth controlling or verifying (doctors and pharmaceutical companies share the same pretense).

Open source hardware can also encrypt, and properly-designed hardware can encrypt without fanout (no feasible side channel attacks). If we choose, we can build individual hardware that encrypts each keystroke and decrypts it at each screen, whether the path between is centimeters or megameters. With proper hardware, you can still use Gmail for your mail host, but your messages are gibberish to Google, and to whoever they share the messages with. Google banner ads can be ignored by your decrypter. Google would starve, so they want to make your software and hardware "for free", protecting their product (which is you).

Hardware geeks will still need to re-examine (identical) copies of the hardware from time to time, to make sure the hardware matches specification, and crypto geeks will need to frequently re-examine the specification to make sure it is mathematically correct. And sometimes the hardware will be invalid, and we will need to replace it with new hardware. But a billion transistors costs pennies from Intel, which Amazon can get to you overnight.

Why this matters to Server Sky

Server sky will use far fewer routers. Access to server sky arrays will be trigonometric, agile antenna pointing, not packet routing via DNS and border gateway protocol; if the array is above the horizon and has what you want, you can talk to it directly without intermediaries, and your conversation can be encrypted end-to-end. Of course, each end can have fanout, with either the orbiting array or your ground terminal copying your conversation to your Designated Overlord. Each end can have a fanout of zero, censorship applied by that same (or different) Designated Overlord. No man-in-the-middle attacks when there is only vacuum and Maxwell's equations between sender and receiver. Orbital mechanics, Doppler shift, and twelve-nines-accurate shared clocks provide link authentication that cannot be spoofed without reshaping space-time.

There will be Designated Overlords - in the US, we call the overlords "Google" and "Hollywood", in China the overlords are the Communist Party and/or the People's Liberation Army. People can't seem to live without chains, sigh. But we must design our hardware so the overlords are explicit in the design, few in number, and subject to organized social opinion (which may be more true for China than the US, though I love Google more than the PLA).

This matters because the Server Sky team will make the design decisions now that will shape the hardware for decades, until the next big re-architecting (the last two were the Bell network, and internet protocol). These decisions should be informed by every capable brain on the planet. They should not be made by me, nor by my handful of smart but fallible collaborators. The best minds work elsewhere, and the best minds, if they know what's good for them, will get involved while the future is still conceptual and easy to shape. After launch, we can still replace all the satellites and all the ground terminals and all the end-user gear, but this is costly, and even the best minds don't have the money and persuasiveness to make this happen often. Better to get it approximately right the first time, and make it plug-upgradable.

This webpage is an appeal for help. Bad social design is easy, and regrettably common. Hardware is easy compared to competent social design. I beg you to help design the future you and your descendants will live in. I goofed up once, I would rather not do it again.

CodeLawHardware (last edited 2014-07-25 03:30:10 by KeithLofstrom)