What is a System-on-Chip (SoC), and why do we care if they are open source?
bunniestudios.com
bunniestudios.com
Proprietary SOCs suck when you run into a bug in system bring-up (and if you are going off the beaten track even a little, you will), and you have a vendor that:
- Doesn't believe you. In fact, is quite vocal about not believing you.
- Takes your hard-won repro code (with "a possible workaround, what do you think?") and is silent for months;
- Finally publishes a TR about that bug, along with your very own workaround code, verbatim and unattributed and you never even got an email acknowledging the issue.
... and after nearly a year of chasing the stupid thing down, as a last resort grants you a five minute phone audience with the chip designer. Sixty seconds into the problem description he says, "Oh, I know what's going on..." and proceeds to fix everything by telling you what parts of the documentation are lies. Your workaround turns out to be how you have to do it. You feel a little ill.
An open source SOC would not necessarily be better understood by more people, but it probably couldn't be worse.
That one was a "don't use these particular memory locations, or disable the cache (which makes the chip unusably slow)" kind of bug, and I'm still simultaneously amazed that I managed to figure it out and angry that I had to.
It was a specific example, one of many from a vendor that I will not name, and over a decade ago.
while technically the literal reading of your sentence is not incorrect, the phrase above is referring to nepotism which is not the issue OP has.
The sample drivers written by the company were all buggy, by the way. They wound up doing a cut-and-paste with our workaround in their next board support drop.
There's a "Linux on LiteX-VexRiscv" design [1] that adds a DDR controller and MMU to the shared bus as well as a handful of other pieces that allow you to boot a Linux kernel image, mount a filesystem, and get a shell prompt over a serial terminal or ssh.
You can then use familiar interfaces to talk to whatever peripherals you decided to include, e.g.:
$ echo 1 > /sys/class/gpio/gpio508/value
$ echo 50 > /sys/class/pwm/pwmchip0/duty_cycle
[1] https://github.com/litex-hub/linux-on-litex-vexriscv
[2] https://twitter.com/gregdavill - He posts a lot of really cool macro and microscope photos of electronics assembly
An SoC is a whole-different beast, because it contains all of the other things needed to create a system, including on-chip memory, I/O, interconnects, possibly some analog components, and it all has to work together. The more complex ones have multiple power domains, circuits that turn off when others turn on, and there needs to be embedded software in some of these devices. Depending upon what process node it was developed at, it also may require multiple voltages and a complex power delivery network. And if you really want to push the performance, you probably want to put this into a complex package, possibly including other chips. Having configurability in there in the form of an FPGA or some programmable logic is an interesting option, which is what Intel has done and presumably what AMD will do with its proposed acquisition of Xilinx. That helps keep it tuned to changes in algorithms for AI and machine learning without having to completely re-do the design.
The challenge will be finding design tools to make sure you haven't messed up anywhere. The free tools tend to be difficult to use and generally ineffective. The commercial tools are much better, but they're also expensive. And the more complicated the design, the more you'll probably need to buy some expensive hardware or lease it from the cloud. Programmability won't solve any of this. It will simply help avoid obsolescence, or at least slow it down.
There's a good article on open source here: https://semiengineering.com/riding-the-risc-v-wave/, with more links at the bottom if you need more.
https://www.hackster.io/news/wave-computing-closes-its-mips-...
IBM also released an open POWER core.
https://github.com/openpower-cores/a2o https://www.phoronix.com/scan.php?page=news_item&px=IBM-Open...
From the article: 1M US-$ at least for the masks plus a boatload of other upfront investment. If you're for bleeding-edge tech like new fab processes, orders of magnitude more.
And we have pretty great open source cpu & ram design tools. MAGIC is free. There's a lot of great tools fora lot of this.
What is not so great is all the un-core. And GPU, if you want that.
The SiFive boards were coming with TileLink[1] as the main way to talk to the core, for a while, I believe, which is a pretty low level cache-coherent fabric used no where else. There's decent off the shelf to design a lot of the digital systems here. But I don't know what resources if any are available to help you build a chip-to-chip interface, to expose the TileLink. And there's basically the world's tiniest market for things to plug in on the other end anyways.
When you buy an SoC, almost all embedded folk expect a bunch of semi-standard capabilities. I2C, I2S, DisplayPort, USB, Ethernet, &c are all common things you might want. While we can make a decent cpu now a days, afaik, we are still in very very very early days, very pre-implementation, for almost all of these. Thusfar almost everyone relies on buying closed IP to provide connectivity for the SoC they are making. It's quite likely to be the case as well for the new SiFive Unmatched board; I expect they bought someone's PCIe IP & integrated it.
We are starting to see more neat work with FPGA implementations of various protocols like USB3 & PCIe but these all rely on the FPGA having really good transceivers that tackle the PHYsical layers, do the dirty work. Building actual transistors to be receivers & transmitters into & out of the chip, that's where, atm, we are all but babes, it feels like.
$70K 20 WEEKS 100 SAMPLES
See also: https://theamphour.com/503-fabless-chip-design-with-mohammed...
Definitely older processes have much cheaper mask sets -- in part because there are just fewer metal layers, and fewer & cheaper masks required to image the transistors when the wavelength of light used (193nm) is close to the line width of the devices themselves.
https://mamot.fr/@pluralistic/105183378364921755
I really think this is the killer point of it all. The cores are the easy part. The digital part. Are we making headway anywhere else? Eh, yes, a tiny bit? Barely?
The promised "November run" did not materialize, and there's nothing solid on rescheduling it.
Kind of a let-down.
The same HDL that can be configured into an FPGA can be used to make chips.
But we won't get there without the FPGA step. Chips aren't designed directly anymore. The sort of complexity we need these days means it's impossible to get right on the first try, and mistakes are very costly with ASICs.
Not exactly, you'll likely have to replace FPGA HW blocks for "hard IP" such as I/O (especially high speed interfaces such as HDMI/DP, MII, but also RAM controllers), power and clock management...
The main attack surfaces to worry about when translating this design to an IC are the RAM, boundary scan and eFuse macros, and perhaps slightly less so the PLL and ADC blocks. While these are not trivial blocks to be worried about, there may be things we can do at a design level to complicate attempts to bake back doors into these blocks, and we're investigating methods to verify their correct in-silicon construction non-destructively.
I always thought those were only half for process control and half to force you to leave a blank spot on your mask where they could pattern in nasty additional circuitry on a few wafers.
Edit: TSMC calls this the "Dummy TCD macro". If you have the 28nm design rule book T-N28-CL-DR-002 version 1.3 it's Section 6.3.3 "Dummy TCD Design Insertion Guideline" (if you don't have the design rule book then no, I can't send it to you, please don't ask). The TCD macro is a black box -- nobody outside TSMC gets to see what's in it. You have to leave a 9um*3.5um empty region on all layers in every 2mm by 2mm region of your maskset.
Now that Multi Layer Maskset (MLM) is widespread every fab has the ability to "blade off" regions of a mask and expose a pattern from a different mask in that region (of course wafers processed this way are much much more expensive). The TCD macro rules force you to leave an empty hole in your design at regular intervals where this can be done without breaking your chip.
Holy fucking hell. So that is what the comment in https://news.ycombinator.com/item?id=24919073 might have alluded to?
Is there any way to take a random TSMC-fabbed chip and inspect this region, or are the feature sizes too small?
Oh, no, it gets much worse. Take the blue pill, turn back from this rabbit-hole now; Here Be Dragons.
Sometimes I find myself double checking if I am really on HN and not on Facebook.
More along the lines of what you're asking-- the virtualization creates a huge attack surface and there is a long history of VM escapes, microarch sidechannels, etc.
>There is pretty much no way to validate the qubes public keys, they're not signed by anything else.
Not sure what you mean here. All Qubes keys are signed by the master key which belongs to the main developers.
Well, not quite:
> "XSA-213 is a fatal, reliably exploitable bug in Xen," said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. "In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213."
https://www.csoonline.com/article/3193718/xen-hypervisor-fac...
> Qubes keys are signed by the master key which belongs to the main developers.
Right, and that master key is signed by nothing. There is no way provided to verify it.
> May 3, 2017
I said Qubes 4+, which was released in 2018: https://www.qubes-os.org/news/2018/03/28/qubes-40/. All previous versions relied on software virtualization (and had much wider compatible hardware).
> Right, and that master key is signed by nothing. There is no way provided to verify it.
Sorry for my ignorance, how does one securely verify a master key not risking to compromise it?
https://www.qubes-os.org/security/verifying-signatures/#1-ge...
If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.
Armed with a valid SSL cert, they MITM traffic. When a target downloads qubes they give them a tampered version, when a target downloads the master key, they give them a lookalike key.
The user can happily verify the tampered qubes with the lookalike key.
PGP proves nothing if you cannot verify that you have an authentic copy of the key.
Qubes gives some handwavy suggestions at how to check the key which do not work.
The first item "Use the PGP Web of Trust." cannot be done because the key isn't signed by anyone. The other suggestions are inapplicable or won't achieve anything if the target's network is being tampered with.
This is not some newfangled problem. PGP has the ability to sign keys for precisely this reason. The main Qubes developers should have personal PGP keys which they use to sign the master key. Their personal keys should be certified by other FOSS developers that they've met (maybe the master key too). Then people who are interested in obtaining high confidence in the key can inspect the chain from their own key to the qubes masterkey.
Obviously not everyone will perform careful validation, but if some do then substituting the key becomes riskier. Unfortunately not only is the key not verifiable at the moment, but the current situation is looks pretty similar to what an ongoing key replacement attack would look like.
> If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.
The malicious party would have to compromise a lot of websites for that: https://www.qubes-os.org/faq/#should-i-trust-this-website.
Apart from that, let's see what the developers will reply: https://qubes-os.discourse.group/t/there-is-no-way-to-valida....
(I'm not suggesting that it is-- it's just an extremely bad failure mode when you undermine your users ability to detect key substitution attacks by always looking like a key substitution is in progress).
Then again, it's not just them. OpenSSL did this previously too-- replaced their key and the only source for the new key was the same https site as the software, and the key was signed by nothing and it stayed this way for a month.
During which time most Linux distributions shipped the new update, which presumably means that they're not doing due diligence either. OpenSSL promptly fixed it after I reported that I couldn't validate their key.
Fedora itself now has a nearly non-verifyable key, unlike qubes they don't even have a master key that signs their release keys or sign new release keys with old ones. Presumably Qubes picked up their bad practices from Fedora.
It used to be that various developers at redhat would sign the fedora keys and post the signatures to the keyservers, but the DOS attacks on keyservers mean they can't do this anymore.
Furthermore, the "blue pill" attack is not a vulnerability in VT-x itself. In fact, it does not exploit any vulnerabilities at all - it simply works off the idea that code running in ring n can hide itself from code running ring+1 (the bluepill hypervisor being ring -1).
https://www.qubes-os.org/security/xsa/. The actual number is 67 in ~10 years: https://www.qubes-os.org/security/xsa/, which is more secure than anything else AFAIK.
Note, this is counting older Qubes versions, where the virtualization was much less secure.
Open source chips are not common place right now, but maybe in like 10-15 years.
Love bunniestudios posts.
If an FPGA SoC of the same power is 250-500x more expensive - how many of the issues of proprietary SoC's become tolerable?
Wouldn't using a non SoC architecture - Processor + support chips become a better solution?
Thus it's overkill for your average user, but if you're a comptroller with million-dollar signature authority on corporate bank accounts or a journalist operating in hostile situations it could be worth the cost.
otherwise, i wouldn't bet he'll come back with all the nails he had in the beginning (maybe if it's disguised as some kind of "stupid" appliance"..)
Also, I don't understand what about AES can be taking up so many LUTs.
Clue, please?
The Rust business appears to be stuff to generate compile-time constants identifying addresses of peripheral registers for (Rust) code written to run on the core. Apparently the addresses change as you add and remove various peripheral gadgets.
It is doing AES rounds sequentially. It might be that real-time generation of round keys uses up a lot of LUTs.
For example, glitching the clock may lead to a repeatable behavior that could only be produced if no additional circuitry has been added to the critical path that leads to the glitch.
No, and that's the big problem.
You can't even tell by grinding the layers off one by one and inspecting them with a microscope. There was a paper published recently showing how to backdoor a random number generator by fiddling with the dopants. No visual difference at any magnification level. I suppose you could test for it with an electron microscope but you'd have to know what you're looking for and where to look.
Librem uses a very proprietary, very closed SoC.
The SoC has decent documentation, relative to the average of what passes for documentation these days, but that's about it.
If you want to try, go here:
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-family-armcortex-a53-cortex-m4-audio-voice-video:i.MX8M?tab=Documentation_Tab
That is FUD. Yes, it is proprietary/closed. To say that it is _very_ proprietary and _very_ closed would imply that it is somehow _more_ proprietary and closed than normal. However, the higher quality documentation available for the i.MX series would make it any more closed. It is ever so slightly more open.
Very was meant to highlight the contrast with a SoC that has open RTL.
i.MX is indeed one of the better documented ARM SoC families.
The use of white space really is too liberal.
Luckily Firefox has reader view, but that shouldn't be necessary to read an article.