>> "
Open source hardware can be manufactured cheaply (about 3 cents per processor) audited for NSA backdoors or vendor backdoors or decade-old exploitable firmware bugs, and built without hidden extra processors in things like storage devices and USB controllers easily repurposed into spyware."
Anyone familiar with J-Core able to expand on the how an audit would be done end-to-end?
Seems like it would be much harder to do in practice than in theory.
You can audit the code, compile, synthesise, place and route the design, tape out masks, send it to a fab, decap a few of the chips you get back and look at it under a microscope. You should be able to compare that to the masks to verify the design hasn't been tampered with.
It's harder to audit ASICs that other people have had fabricated without having the exact same standard cell libraries, tooling versions (optimisations change over time), knowing what optimisation settings they used, etc. to be able to prove the masks came from the same code.
Generate masks, look at them and validate that they only implement the circuits your VHDL synthesizes. Make a wafer and validate that the silicon is the same as the masks. Get your wafer diced and hand carry it to Malaysia to have it put into packages for you. Pretty time consuming though.
You might be able to get away with a strict characterization of the diced chips to give yourself a very high likelyhood that different die were not substituted at the packaging step. You could also decap a random selection of chips coming back from the factory to validate they used your die rather than a different one.
In this talk https://news.ycombinator.com/item?id=12101908 they said their toolchain can output layouts for the CPU on silicon, and it would cost about $25,000 to have photomasks made, and I think about $0.50 per chip.
But it's not a duplicate - they have different information. This submission is the web site of the project and has links to files and "how to" documentation. The second submission is to an hour-long about the project, and while it contains information, it's fundamentally different.
I don't know why the original submission of this link got marked as a duplicate - I believe it to have been a mistake.
This is really getting annoying. I submitted this same link 14 hours earlier (https://news.ycombinator.com/item?id=12103471). It was flagged as a dupe (even thought it wasn't at the time) and killed. (It has since been unflagged, but of course it's too late to save it now.)
I agree with you entirely, which is why I resubmitted it and made the extensive comment[0] about why it is not a duplicate, and deserves to be here in its own right. If I could gift you the karma I would, not that it's really worth much, to be honest.
The current method of handling duplicates is quite simply not working. Consider the multiple large discussions about Google deleting a blog without warning[1][2][3].
HN needs a way to merge items, not simply mark some as duplicates, which kills the item, and any discussion on it then sinks without trace. There must be a better way.
[+] [-] raverbashing|9 years ago|reply
"Numato provides a GPL-licensed python3 tool to flash bitstreams onto their board. [TODO: port to python 2]"
No, please. Don't even bother
[+] [-] nickpsecurity|9 years ago|reply
[+] [-] nxzero|9 years ago|reply
Anyone familiar with J-Core able to expand on the how an audit would be done end-to-end?
Seems like it would be much harder to do in practice than in theory.
[+] [-] stephen_g|9 years ago|reply
It's harder to audit ASICs that other people have had fabricated without having the exact same standard cell libraries, tooling versions (optimisations change over time), knowing what optimisation settings they used, etc. to be able to prove the masks came from the same code.
[+] [-] ChuckMcM|9 years ago|reply
You might be able to get away with a strict characterization of the diced chips to give yourself a very high likelyhood that different die were not substituted at the packaging step. You could also decap a random selection of chips coming back from the factory to validate they used your die rather than a different one.
[+] [-] coderdude|9 years ago|reply
[+] [-] npx|9 years ago|reply
[+] [-] analognoise|9 years ago|reply
What about the "to silicon" part of this equation is out there now?
[+] [-] tlrobinson|9 years ago|reply
[+] [-] CarolineW|9 years ago|reply
https://news.ycombinator.com/item?id=12103471
However, that submission was incorrectly marked as a duplicate of this submission:
https://news.ycombinator.com/item?id=12101908 (video)
But it's not a duplicate - they have different information. This submission is the web site of the project and has links to files and "how to" documentation. The second submission is to an hour-long about the project, and while it contains information, it's fundamentally different.
I don't know why the original submission of this link got marked as a duplicate - I believe it to have been a mistake.
[+] [-] sctb|9 years ago|reply
[+] [-] lisper|9 years ago|reply
[+] [-] CarolineW|9 years ago|reply
The current method of handling duplicates is quite simply not working. Consider the multiple large discussions about Google deleting a blog without warning[1][2][3].
HN needs a way to merge items, not simply mark some as duplicates, which kills the item, and any discussion on it then sinks without trace. There must be a better way.
[0] https://news.ycombinator.com/item?id=12105922
[1] https://news.ycombinator.com/item?id=12097063
[2] https://news.ycombinator.com/item?id=12099757
[3] https://news.ycombinator.com/item?id=12100843