J-core Open Processor | Hacker News Reader

J-core Open Processor

j-core.org

177 pointsCarolineW27 comments

Open articleView on HN

Interesting that's still and nommu system. Maybe as soon as the patents expire we can get the mmu system.

"Numato provides a GPL-licensed python3 tool to flash bitstreams onto their board. [TODO: port to python 2]"

No, please. Don't even bother

What patents? All kinds of CPU's have MMU's. Implementations go back decades. Cant imagine a patent risk for MMU's.

Patents for SH4 as described in the article (this is an SH2)

>> " 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.

Is spot checking good enough? Wouldnt you need to follow every trace?

In hardware, implementing a backdoor that provides a reasonable level of functionality is probably going to cause a visible change to the layout/routing, kind of like a software backdoor is going to change the hash.

I say probably because it's possible that advanced actors like the USA and China have developed tools that add features (backdoors) while making the visual layout look very similar. Then you would probably only find the backdoors by "fuzzing" the chip like you would a piece of software.

There are hardware backdoors that require only dopant-level changes, see the second comment here:

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

It feels like trying to fend of anything but automated drive-by attacks online will be a fools errand.

You can do it with a single gate and a handful of passive parts. http://ieee-security.org/TC/SP2016/papers/0824a018.pdf

The masks can be converted back into a netlist and then a formal Logic Equivalence Checker can verify correspondence with the original HDL.

That won't protect against the dopant level attacks, but you could have an automated test run to ascertain dopant levels on chips that you decapped - if you want to take paranoia to the absolute limits. That would take serious time and money to setup computer controlled micropositioners and expensive source measurement units, etc.

Iirc, there was a group from the CCC working on using image recognition algorithms to extract netlists from decapped chips. I'll have to look that up...

The weak link there is the masks. It's rare for the company creating the design to make the masks unless they are their own foundry.

And many foundries themselves outsource masks due to equipment costs.

Expound, not expand. This is how "begs the question" got a brand new meaning.

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.

Tremendous work as always from Rich Felker, Rob Landley, & co.

I'm interested, but mostly in the part where we get to silicon - implementing yet another CPU in VHDL isn't all that uncommon.

What about the "to silicon" part of this equation is out there now?

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.

I haven't seen that part of their toolchain; that's where I'm interested. Also, seeing a successful test of this toolchain in working silicon, with a known vendor and a good process, would be extremely helpful for the community (if other people are going to get aboard, which I hope they are).

Look up Qflow open-source flow. It's the likely toolchain OSS projects will use. Combines Yosys front-end, ABC backend, and custom tool (Qrouter) for routing. Worth evaluating.

Yosys is a Verilog front-end; this is being designed in VHDL.

It looks like there is a translator, but I'm unsure about its license, source availability, and capability.

In the interests of full disclosure, this was submitted earlier here:

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.

We've unmarked the previous thread as a dupe.

While I appreciate the action, it's too late. That item has sunk now without trace, and while karma isn't actually worth anything, it would have been nice for that original submitter to get the associated karma for finding this, and not me.

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.

[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

Ah, I missed that. Thanks for the shout out!

I've given some thought to how a more fair submission system would work, and I came up with the following idea:

1. Dup submissions are treated as upvotes

2. If an article has N upvotes, the original submitter gets N points (as it is now), the second submitter (or upvoter -- same thing) gets N/2 points, the third gets N/3 points, etc. until either the article makes it onto the front page or some arbitrary point threshold (like 10) is reached.

3. Every upvote or submission costs one karma point. So you have to have at least one karma point to submit or upvote. You have to get your bootstrap points by submitting a comment that gets an upvote. This is to prevent spamming.

Reply on news.ycombinator.com