Hacker News Reader

I agree, open source hardware (and especially open source silicon, where there are such huge barriers of entry) is very much different to open source software. It's possible that a breakthrough in direct-write lithography or similar would help to reduce these barriers, but it's not something we're betting the project on. This is one reason why our hope isn't to produce just one iteration of the lowRISC SoC, but to have a regular tapeout schedule. This means if you make a contribution, you know you'll be able to see it on shipping silicon on a reasonable timeline. Another part of this story is, as with minion cores, in moving more aspects of the design from fixed hardware to being software configurable.

As to your second point, I agree - open source hardware is no silver bullet for unearthing malicious backdoors. Being able to audit for unintentional issues is useful, but yes - you need to secure or trust your supply chain to know that the chip you have in your hands matches the open RTL.

> The second limitation is that it is impractical to audit the hardware to determine whether you have actually received the unmodified open source design. For software this can be achieved using reproducible builds or just by compiling it for yourself.

Mostly too expensive AFAIK. I'm fuzzy on the details, but it should be possible to create high-resolution (e.g. X-ray) scans of the chips (as is done by chip design pirates) and compare them to known-good implementations, or images generated based off the chip's open-source design.

I'm looking forward to a future where PC auditing shops are a thing. Take in your machine, and let them verify the contents of every chip and storage unit on your device.

Is there really an imaging technology that is high enough resolution to capture the detail of a modern CPU?

And if so, would that be sufficient for an audit? Aren't CPUs dependent not just on the layout of circuits but also on the material properties of the components, which might not be apparent just from images?

This is true, imaging a die can help but it's not enough for full assurance. See e.g. this work on inserting hardware trojans through changing the dopant levels on transistors http://sharps.org/wp-content/uploads/BECKER-CHES.pdf

Worse, there isn't currently any nondestructive chip imaging technology!

That just increases the verification costs: order ten chips, verify five randomly chosen ones. If all five are clean, the other five are probably also clean. Modify numbers for the desired cost/risk trade-off.

They aren't going to be able to counter analog malicious hardware or dopant level attacks:

https://lwn.net/Articles/688751/

Perhaps this is a solution?

http://engineering.nyu.edu/press-releases/2016/08/23/cyberse...

> The first one is that even though you can modify the design, you have no practical way of using your modified design (at least in this context, because FPGAs are slow and expensive and high performance SoCs don't fit anyway).

You can test your improved design against the old design on an FPGA, and if the test results look good, the maintainers of the mass-produced version might merge your change request and incorporate it in their next generation.

Of course, that won't help you if your optimization only helps niche applications, but then again, if it's that niche, you weren't going to get a mass-produced SoC in the first place.

> The second limitation is that it is impractical to audit the hardware to determine whether you have actually received the unmodified open source design. For software this can be achieved using reproducible builds or just by compiling it for yourself.

This is one of the things I'm hoping to study further during my PhD. I have a lot of reading to do before that, though :P

Of course hardware is different than software. But the goal is noble. Would you stop it, just because there are "limitations"?