5 ms·
Shameless blog post, but I wrote about something similar here. [1] The TL;DR of it is that I think the hardware industry is in the exact same spot as the softw
by ljhsiung 5y ago
Shameless blog post, but I wrote about something similar here. [1]
The TL;DR of it is that I think the hardware industry is in the exact same spot as the software industry was 20 years ago; a wild west of security. And I think the only way out of this is with decades of good tools, infrastructure, and methodology development.
That's not to say software security isn't a mess right now-- it also is. But at least we *know* relatively how much it's a mess. With hardware, it's an unknown unknown, the worst kind of unknown.
[1]: https://ljhsiung.com/posts/the-state-of-cpu-fuzzing/ https://ljhsiung.com/posts/the-state-of-cpu-fuzzing/
- not2b 5y agoThe semiconductor industry was using fuzzing before it was used in software (starting about two decades ago), but they didn't call it that. They (or rather, the academics who pioneered it) called it coverage-directed constrained random simulation, and it worked in much the same way as modern fuzzers do.
- snovv_crash 5y agoI wonder if you could fuzz a chip directly, without having the schematics, so that if the manufacturer inserts something off-the-books it still gets explored.
- not2b 5y agoFor fuzzing to be effective you need access to coverage information. If you have the RTL (SystemVerilog or VHDL source) you can verify that you're hitting all the paths and the branches, and use a constraint solver to find paths that increase coverage. If you just have the registers and latches you can see how much of the state you've reached. But if you just have a chip too much of the internal state is unreachable: you'll never find the magic sequence that triggers the badness (if it exists) by random simulation, the heat death of the universe will happen first.
- snovv_crash 5y agoWhat if you had some kind of microscope which could see which gates get activated?