Hi, I’m a lurker. I work on CPUs. This also motivated me to post!
This is a rather niche topic, but I want to express it, because I greatly enjoy seeing other ramble about their deep-work domain expertise, so maybe someone will find this interesting too? This is relatively similar to the concept behind the podcast [What’s your problem?], in which engineers talk about ridiculously niche problems that are integral to their field.
Anyways—here’s my problem.
Fuzzing (maybe known as mutation based testing, or coverage directed verification, or 10 other different names) has, in my opinion, been revolutionary for the software security industry. [AFL] is probably the best and most successful example, and I think most people would agree with me that this tool has saved millions of manhours in finding security vulnerabilities.
Why don’t we have such tools in hardware? Well, my personal opinion is that EDA tools are rather monopolistic and cumbersome relative to e.g. GCC (e.g. imagine paying millions of dollars for a GCC release!), and a partial side-effect of that is that the language hardware codes in (verilog, systemverilog) is so ingrained we can’t get out of it.
This is just barely starting to change.
[Here] is my personal top favorite of a contender. What makes this cool is not entirely revolutionary new ideas, but rather the sheer amount of effort to make things just work is truly truly commendable.
The main perk of fuzzing is, frankly, finding low-ish hanging fruit. Just like how buffer overflows are, in some sense, a “known problem”, there’s a plethora of hardware vulnerabilities I’ve found that you wouldn’t believe are insanely easy to find. And I firmly think this can be done by simple fuzzing.
My project plan? Convert the detected vulnerabilities into generated exploitable software vulnerabilities. And I think the above project can fit into the “detection” aspect—honestly still a WIP for me to evaluate how good it is, or how complicated the fuzzer is (most of the time it’s just a wrapper around SMT solvers), but it’s something I’m excited about.
(On the “exploitable vulnerabilities” end, there is similar work [here], but I’ve done some experimentation with this and still find it rather cumbersome for a variety of details I won’t get in to.)
I’m unfamiliar with the Berkeley area, is there a recommended parking area/garage?