Die photos and analysis of the revolutionary 8008 microprocessor, 45 years old
righto.com
righto.com
In 2011, I donated a mass of Mac computers to a podcaster who wanted to set up a museum of Mac history. It was a lot of work.
Not news to the HN readers, but yeah: computers used to be even more difficult to use than they are now. And of course getting all of the bits together for a working system takes a lot of time.
When you look that notion of the 8238 you can see the seeds of the 'south bridge' that was so prevalent in PC design. Intel systems broke apart as "memory" (northbridge), "compute" (cpu), and "i/o" (southbridge). That has been a pretty successful architecture and one that ARM would do well to emulate for their non-SoC offerings.
And considering that regular color printers (inkjet and laser) have all been backdoored for ages - they print mostly invisible constellations of dots into every page which identify the individual printer - I would say that backdooring a "silicon printer" is also a definite possibility.
The Soviets were doing that back in the 40s[0]
[0]: https://en.wikipedia.org/wiki/The_Thing_(listening_device)
With circuit design, fully independent verification has not been solved yet. The primary reason is that fabrication, especially at lower process nodes, is extremely complex. So even if you had a "3D IC printer" at home, you still need to trust the manufacturer of that printer, as well as the manufacturer of the key components of the printer. Taking that even further, you need to trust that each of those components was manufactured by a trusted fab. It's turtles all the way down.
If I were to design such a printer from scratch, I would have a consortium of known companies oversee the design of the first printer and all of its components in a closed environment with 24/7 surveillance. All circuits would be fabbed using a manual, low volume process. Once the initial printer is complete, all the circuits of subsequent printers would be fabbed using this root printer. There are shortcomings with this technique too, but it's probably the best way to go about doing it (with current tech).
Besides, the fab itself isn't the issue. Rather, the equipment used during the fabrication process itself are the weakest link, so to speak. Further, if we consider the feasibility of insider attacks, the people who maintain the fab are potential targets as well.
So, I think achieving what you propose would require: 1) access to an immense amount of resources, 2) the capability to self-manufacture the tools required to manufacture ICs, and 3) an AI that can operate the fab.
The third point alone is so far off that I'd conclude it's going to be impossible for a long time.
The most likely attack would be an override of the code protect/security fuse/anti-JTAG features. But that's only useful when the attacker has got hold of the device and is probing it.
This is precisely the essence of my question, given that I have little knowledge of FPGAs and have no real clue how much each reprogrammed circuit has in common with any other. :)
Very little. An FPGA is a set of reprogrammable logic blocks (LUTs) of very small size, plus a number of special purpose peripherals. The "layout" process of assigning functions to LUTs is usually done with simulated annealing and random perturbation. The compiler won't necessarily give the same output from the same input, let alone slightly different input.
The fixed-function blocks and any embedded processors (e.g. Nios) are more targetable. But you could also e.g. set up the clock PLL to leak the FPGA configuration slowly via spread-spectrum modulation.
A genetic algorithm, by contrast, encodes the system into a "string" (like a DNA strand), and then swaps pieces of strings between two "organisms," just like genetic mating does. The most optimal descendants are kept, the least are discarded, and the process is repeated. This would be harder to implement for locations, as you would have to encode locations onto a string, and be able to swap pieces of strings while maintaining the functionality of the LUTs.
Now, the FPGA is not necessarily an ideal place to insert your circuit; personally, I would put it in something like one of those flat ribbons which connect components inside so many devices, or a socket - they may have access to all the bus pins of the gadget, and they will be less conspicuous. I don't think 3D printing is the answer to this, since too many things would have to be 3D printed.
Now, I don't know how I would go about protecting from such attacks, or if this is even a real-life concern right now, but I would think that some kind of automated high-resolution X-ray imaging and analysis technology would be a more realistic direction.
I believe there was already an incident in this direction were researches discovered vendor master keys for these functions in FPGAs.
[0] http://hackaday.com/2010/05/13/transistor-fabrication-so-sim...
The short answer is that there is no known way round the very nasty chemistry, requirement for clean room, and so on.
http://pastraiser.com/cpu/i8008/i8008_opcodes.html
1/4 of the opcode space is moves and 1/4 is ALU ops. It is quite RISC-like in its simplicity, although it does contain memory-register ops.
The octal encoding goes back to the Datapoint 2200, which use BCD decoder chips (7442) for instruction decoding. These were used to decode three instruction bits at a time, so the instruction set of the Datapoint 2200 (and thus the 8008) was based on groups of three bits. Among other things, that's why the 8008 has 7 registers (A, B, C, D, E, H, L) - the 8th value was used to indicate a memory access.
Also see "x86 is octal": http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt
We laughed about it that it was old, but pretty much everything still applies in today's micocontrollers
However, this kind of power supply routing (not sure Am. call it idiomatically, some here call it a "ladder supply/layout") has poor electrical properties, unsuitable to operating logic beyond a couple MHz.
Thanks! :)
http://www.cs.princeton.edu/courses/archive/fall09/cos126/le... (see next to last page)