XuanTie C906 based Allwinner RISC-V processor to power $12 Linux SBC's
cnx-software.com
cnx-software.com
From https://www.anandtech.com/show/15991/hot-chips-2020-live-blo...
0.7.1 and 1.0 will not be compatible IIRC thus Linux distribution most likely will not support RVV on this.
I presume "brave" was used ironically. It would be very unfortunate if it fractures the ISA but I'm optimistic that it will not.
This is much better than not having support at all, particularly if you want to play with a recent draft, which should be what they implemented.
Support and documentation was non-existing last time I looked.
Has this changed recently? Is there mainline support for AllWinner now or is this still a copy/paste crapfest with branches and huge patchsets?
That said, upstream support for AllWinner parts has come a long way and continues to improve. I wouldn’t mind using them in certain projects.
However, anyone who absolutely needs good documentation and SoC support needs to stick with a vendor that emphasizes openness and good documentation. NXP i.MX is the safe choice.
I wish the HW companies either document their devices or pay someone who understands software to work on it instead just releasing nearly working prototypes and then continuing to another project abandoning HW with old kernels.
I got burned by AllWinner once and will not buy devices using them unless I have a very good reason. :)
They're not going to be unnecessarily reinventing wheels, which should mean we're already half there in these new chips being well-supported by mainline kernel[0].
Still better than Broadcom... at least you can find the (very long) datasheets for a lot of their SoCs.
Never build a product around chips you can’t access anyway. Using the Broadcom Raspberry Pi modules is a great option if, and only if, the features you need are already well supported and documented.
Have to chuckle at this one. I worked for a large company that actually got support from Broadcom for a newer part family (StrataGX). The support was dismal. You'd ask an FAE questions, they'd shrug, if you pressed hard enough (and got your executive team in the loop) you'd get an "answer" from the factory which was usually a pile of badly commented Verilog excerpts under NDA. Thanks but no thanks.
Oh and that one time we did get sample code it was a dump of someone's development directory, including project files for another company (you're probably have one of their machines in your office right now). That was fun.
Also, their requests to plug in "logic analyzer" on the PCI-E bus between host CPU and their chipset in finished product where everything was using BGA soldered parts - yeah...
I believe the only reason everything they share with you is under NDA so you don't go and publicly tell how bad they really are. They are like Boeing to me, but I yet have to see their MAX-like mistake.
Take a look at this fella: http://sam.zeloof.xyz/first-ic/
The page has a short video goes over some of the tools and materials that went in to making a small amplifier chip.
I don't have any experience with making integrated circuits but just from the looks of it, scaling it up to make an entire processor seems a little far fetched.
If you're in it for the fun of having a small project you can pretty easily make your own PCB and solder microchips onto it in almost any home garage.
If not, there's still knowledge of older, but decent processes like 130nm/90nm, which should be doable pretty fast...
It's like the Saturn V - the documentation/blueprints/etc was massive, secret, spread all over, making it basically impossible to recreate the rocket just by "following instructions", replacement stuff would have to be recreated from scratch.
The US has tightly controlled the export of advanced processes, which is why even TSMC isn't allowed to manufacture in China with processes below 22nm.
I believe (Chinese based company) SIMC has a new 8nm process they developed themselves, but people have doubts about the yield.
See https://warontherocks.com/2020/06/the-chip-wars-of-the-21st-... for some details about this.
What's more we are constantly building new plants and processes. This isn't like the Saturn V where the plans were mothballed.
Sure, if you killed all semi-conductor engineers, and everyone at Intel and TSMC and Samsung I'm sure there would be problems. But realistically chip manufacture is one of the things I'd feel more confident about being able to recover.
...probably equivalent in performance to a minicomputer from the 70s.
I.e.:
- space
- power and cooling capacity
- freshwater and wastewater capacity
- legality of storing / disposing of toxic materials
- proximity to a residential dwelling
- equipment cost
- amount of noise produced
It's simply amazing how bleeding edge modern fabrication is.
At the moment all that's available to order is the HiFive Unmatched, with delivery in "Q4" (this year hopefully!). RIOSLab SBCs (https://rioslab.org/) should be coming next year.
If you want to run RISC-V today, use QEMU: https://fedoraproject.org/wiki/Architectures/RISC-V/Installi...
Very Terminator'y :-)
If you want a "desktop" experience then buy a pi4.
This is a pipe dream, but having self-managed local foundries (à la hackerspace) would be awesome to ensure that RISC-V stays secured, decentralised and competitive.
I think you are confused. RISC-V is just an ISA, not a hardware design, so it can't have a backdoor or, on the other hand, be free of them.
With a closed ISA, the only manufacturers are closed-source and I can't verify the chip is secure under any circumstances.
With an open ISA, I may not be able to verify all designs are secure, but, I can verify that some are secure and choose one of those.
You are conflating the ISA with its hardware designs. I'm not an expert, but imagine an ISA being like a C library API, in that case the hardware would be the APIs implementation.
Although fabless design companies like Allwinner and fabrication companies like SMIC both exist in China, there is accessible pathways to China-free chips, especially if you're willing to pay the premium for TSMC's high end manufacturing.
You can't have a manufacturing-hostile environment here in this country and expect to be able to buy phones that are owned by you instead of President Xi and just on loan to you.
Remember the fight over clipper chips? We've rearranged the electronics industry so that everything has a clipper chip, it's just outsourced and you can't see the details.
(I say this like all of y'all reading this aren't younger than 35 and _remember_ the clipper chip).
It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against that design to check for backdoors?
I think the closest you're going to get to "verifiably secure" is an FPGA based core.
The idea would be to somehow scan the design of the chip, presumably using an electron microscope as progre said, and compare it against the design's netlist. This isn't something I know much about, so perhaps it's not at all practical, but at least in principle this should be possible for chips with open designs.
> You could thwart all that with a microcode layer anyway.
I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one on your chip.
> I think the closest you're going to get to "verifiably secure" is an FPGA based core.
I agree that's the most practical solution.
You're missing the fact that microcode lies between the hardware and the user-supplied machine code. Thus hardware+microcode is what has to be verified.
What there will be is a 0-stage boot ROM -it's not microcode, just RISC-V code -essentially the code that knows how to get from the first instruction after reset up to and including the loading of u-boot (or whatever) - if you're interested in how open a system is ask to see that code, and all the code that runs in m-mode (probably u-boot-spl and opensbi both of which are open source)
If it's open hardware, I presume they'll publish the microcode.
So you need to scan the microcode; this demands care I think. Whatever you are reading could be reporting itself incorrectly, if you were to read it through software (that is itself influenced by the microcode). One solution would be to have a hardware module, a verified function that dumps the microcode and cannot be significantly influenced by the microcode itself.
Another issue could be program obfuscation, where you hide behavior inside your program. Since microcode is quite small, I guess the risk is also small.
As a curiosity, as far as I know Cryptographic theory at this point hasn't proved whether efficient white-box obfuscation is possible! (specially for the case of obfuscating cryptographic keys), but there are some proposed methods that generate very large obfuscated programs, and there are several manual techniques (by experienced programmers) that make it difficult to decode to figure out function (we don't know if this could be generalized and automated).
I do think that microcode opens up the possibility of subtle injections to follow code/hardware paths you might not easily predict.
A really good talk on reverse engineering an ISA implementation: https://youtu.be/KrksBdWcZgQ
As far as I can tell from the software world though, it's pretty rare for anyone to try this kind of thing. When their software is Free and Open Source, some companies put telemetry in there (e.g. Visual Studio Code), but it's very rare for there to be anything this malicious hidden away in publicly viewable code.
The Linux world has collectively agreed to trust SELinux, for instance, despite that it originates from the NSA.
The term open source was used in the article, but did they mean that in an accurate sense, or was it just empty marketing? Also, I can't find the source after a short search.
> Could the chip be compared against that design to check for backdoors?
Don't know, but I'm sure much expertise, man-hours and expensive equipment would be necessary. Maybe prohibitively so.
That chip is literally an explicit backdoor.
Authentication worked by the phone displaying a hash of the session key, and the two users were expected to read the key hash to each other and recognize each other's voices. If they were being MitM'd, they wouldn't have identical session keys. Alice and Bob's authentication procedure would then still work just fine, since they'd still have identical session keys.
If the government were wiretapping Alice, they'd of course detect the tampering because they'd be getting garbage data/failed checksums, but otherwise, the tampering would be undetectable, and Alice and Bob get hardware-accelerated 80-bit Skipjack encryption of their data stream, back when 56-bit DES was generally considered reasonably safe and 80-bit symmetric keys were considered sufficient for data classified SECRET and below.
(Or maybe the tampering could be detected when the wiretappers went to look up Alice's fixed DH public key and couldn't find it in their escrow database... I forget if the escrow worked by having a database or if the chip encrypted the DH secret key with a master key and transmitted it at the start of every session. In any case, the whole thing wasn't that well thought out. It's also possible the DH exchange was signed using a malleable signature scheme using the same prime as DH, allowing Alice to raise the DH public key to a known-only-to-Alice power and calculate the power needed to raise the signature in order to still get a valid signature on the modified DH public key. Clearly, I forget the exact details.)