zlacker

Ignoring for the moment all the indeterminism on a running laptop, the main reason is that we don't have the tooling to do that.

For example: compiler is to software as X is to hardware. What is X? And how does one go about creating their own X?

replies(3): >>BenjiW+P4 >>falcol+hq >>nickps+r31

>>jancsi+(OP)
If X is "foundry" you probably can't create your own. And I think it is.

>>jancsi+(OP)
Ultimately a compiler is just a bit of software; one that takes inputs and produces outputs. The identification of compromise is the difference in outputs for the same inputs (simplified, of course).

So, given we can control most inputs to hardware, and most outputs, it seems possible to objectively identify when the HW is misbehaving (such as "A" produces network output that "B" does not). It wouldn't nail down which piece of hardware was compromised, but it would help identify that hardware is compromised.

It will never be _that_ easy, of course... but it seems possible.

replies(1): >>jancsi+ZQ1

>>jancsi+(OP)
Once you learn digital design, you learn how tools like this works:

http://opencircuitdesign.com/qflow/

Start with a simple CPU and memories you can hand-check sent to a 0.35-0.5 micron fab that's visually inspectible. Then, after verifying random sample of those, you use the others in boards that make the rest of your hardware and software. You can even try to use them in peripherals like your keyboard or networking. Make a whole cluster of crappy, CPU boards running verified hardware each handling part of the job since it will take a while. You can use untrusted storage if the source and transport CPU's are trusted since you can just use crypto approaches to ensuring data wasn't tampered with in untrusted RAM or storage. Designs exist in CompSci for both.

So, you'll eventually be running synthesis and testing with open-source software, verification with ACL2 a la Jared Davis's work (maybe Milawa modified), visual inspection of final chips, and Beowulf-style clusters to deal with how slow they are. And then use that for each iteration of better tooling. I also considered using image recognition on the pics of the visual trained by all the people reviewing them across the world. More as an aid than replacing people. Would be helpful when transistor count went up, though.