Precursor – A mobile, open source electronics platform
bunniestudios.com
bunniestudios.com
While writing this comment, I discovered that there's a website selling new old stock? Can't vouch for its authenticity, but you should go for it! https://shop.pocketchip.co/collections/frontpage/products/po...
If you want a small device to play old games on via an emulator, I can recommend Pocketsprite [1]. You can even assemble one yourself.
FWIW, I'm looking for a small portable screen (1080p, IPS) to combine with my MBP 2015 (via TB2 or HDMI but I also want it to have USB-C for future compatibility).
However, Precursor is more about evidence-based hardware security, and less about features and usability. To better understand the principles behind Precursor's design, please have a look at https://www.crowdsupply.com/sutajio-kosagi/precursor/updates....
The TL;DR is that it's a development platform for applications that strongly require secure and/or trustable hardware.
https://hackaday.io/project/164845-dlt-one-a-damn-linux-tabl...
But if it's well-marketed to the hobbyists, and software support is adequate, then maybe.
Mid-to-high 5-figure to low 7-figure unit sales (for a 'wildly' successful device like the Raspberry Pi) is what it seems to be looking like for a successful open mobile(-ish) device. As long as the businesses offering them are sized appropriately, it's doable. Just need to be smart about re-using enclosure designs etc and have long production runs to help amortize things like regulatory certifications etc. For hacker devices, they can sell this stuff for several years between major revs and their customers appreciate the longer product/parts availability.
Sadly, most of these points are mutually exclusive. Android tablets are built for the average user who would have neither use for an hackable OS nor for exposed GPIO ports. Adding them would represent an added cost with no returns with respect to the market they're into. Also, most if not all Android tablets - actually their manufacturers - are hostile to letting techies install their OS of choice, and implement tactics to discourage them, mainly keeping the hardware closed. To date, the Pinetab seems the best example of a tablet designed from the ground up to be of interest both to users and tinkerers because it encourages to experiment with open operating systems. https://www.pine64.org/pinetab/
https://www.kickstarter.com/projects/745629624/cutiepi-raspb...
Is there something I'm missing that means developing a new OS (https://github.com/betrusted-io/xous-core/) works better for Precursor? Keen to understand the rationale, cause I think I'm probably missing something here!
edit: There's a good explanation on the CrowdSupply page - seems like it's in order to make it a more secure platform:
> Simplicity addresses the reality of only having 24 hours in a day. Even though the full source code for the Linux kernel and Firefox is published, nobody has the time to personally review every release for potential security problems; we simply trust that others have done a good job, because we have no other choice. Precursor rolls the clock back to the early 2000’s, when mobile computers were powerful enough to be useful for single tasks, while simple enough that individuals or small teams could build them from scratch. But don’t worry, despite its simplicity, Precursor’s computational capability exceeds that of the Palm Pilot series. It’s more on par with a Nintendo DS: sufficient for core security tasks such as authentication, instant messaging, crypto wallets, and even end-to-end encrypted voice calls.
(Not that it's an easy with a simpler software stack either of course but you can have a fighting chance at least)
This formfactor, combined with a LoRa transceiver would be epic as an off-grid or fallback comms device.
I get fuzzy cyberpunk feelings imagining it.
Bunnie's projects are always intriguing. I'm still amazed by the investigation into sd card controller chips.
Sticking LoRa in this would be awesome, (e.g. https://www.meshtastic.org/), but I can understand why it has wifi.
Definite cyberdeck potential
Just the other day I found out about WiPhone: https://www.kickstarter.com/projects/2103809433/wiphone-a-ph...
The project appears to be in a "limbo" state.
> if your application does not require a large display and a keyboard, you can simply remove them and replace the bezel with a full-sized circuit board
If that's too ghetto for you, have a look at the M5Stack series. A main unit (ESP32, screen, speaker, TF card reader, in a case with some buttons) costs $35, and the battery module you can stack on is $10. There is even a keyboard and a gameboy-like attachment.
I like the look of the Precursor, but personally the FPGA is a bit off-putting, just because I've never gone down that road.
One thing I can't find any detail on is the keyboard. Making a keyboard from scratch is well outside of usual low-volume productions and there aren't any readily available parts in this form factor as far as I know. How is the Precursor's one made/sourced?
I'm using a Blackberry keyboard for my project, but that's obviously not scalable.
—
I find this device extraordinarily appealing (will definitely be backing). Bunnie is a hardware hacker’s hacker, the project has at least 2 years of development behind it. It will most definitely ship, and work. Ha.
But — I’m specifically excited because this seems like an ideal platform to build whimsical mobile hardware projects.
My dream of a 2000-era electronic organizer with a “retro” (non touch) display, with physical keyboard, and battery, and programmable/hackable and fully open... this is truly a dream come true.
Why couldn’t this become the democratizing mobile Arduino-like hobbyist “base”?
I’m extra, extra excited about it!
(And dream of adding LTE and making a retro minimal... phone OS/“app”? Fast email + wikipedia clients??)
The accelerometer is the LSM6DS3, I'll refer you directly to the manufacturer's website: https://www.st.com/en/mems-and-sensors/lsm6ds3.html
You can find out more about how it's integrated at https://github.com/betrusted-io/betrusted-hardware/blob/mast... (note: this is a "DVT" schematic, bugs were found, they are currently being fixed, but they aren't related to the accelerometer).
The TL;DR is that the accelerometer is integrated so that it's in the "always on" untrusted domain, so to access it from the main FPGA "SoC" you have to go through the system controller FPGA ("EC" as we call it). The idea is for it to be available in power down states for anti-tamper, hence the extra layer of complication.
Talking to it requires a call to the EC via the "COM" bus (https://github.com/betrusted-io/betrusted-soc/blob/master/fw...). The EC driver itself is based on the C-native library provided by STM and translated into Rust bindings. It's a little gross: https://github.com/betrusted-io/betrusted-ec/blob/master/sw/...
Hope that helps.
Well, for one thing, the XC7S50 FPGA costs over $50 just for the chip. This device is going to be much more expensive than an Arduino or even a Raspberry Pi.
I do hope that the form factor, “polish” — how much of a finished product the Precursor is, and the possibility of programming/extending it can serve as an inspiration/starting point for future hobbyist mobile tech.
I know that it’s a very heterogeneous mix, but just to note some contemporary devices that evoke “similar” feelings: Panic’s Playdate [0] and the recently crowdfunded Flipper Zero [1].
Maybe all of these remind me in some ways of the Gameboy, electronic organizers from the 2000s [2], pre-smartphone Symbian Nokias [3] (and every qwerty/slide out keyboard device from back then), all of which I grew up with.
But, it also seems like there’s a lot of interest now to create digital experiences that aren’t tied to existing social media platforms, aren’t engineered to simultaneously maximize addiction and profit (through advertisement and the sale of personal data).
Developing towards that future is immensely exciting.
1 - https://www.kickstarter.com/projects/flipper-devices/flipper...
2 - https://en.m.wikipedia.org/wiki/Electronic_organizer
3 - https://www.pcmag.com/news/the-10-best-symbian-phones-ever
Is that possible, in principle, in a Spartan 7?
It is easy to believe that you would need to pre-generate bitstreams for each configuation, and could only swap them in verbatim, not generate them on-the-fly, but downloading from a library, perhaps with parameterized choices, could increase flexibility.
In the specific case of Xilinx FPGAs there was a feature introduced in the original Virtex called "partial configuration". This has been present in all its products for the last 20 years. It allows a design to be broken into parts such that one part may be replaced even while the rest of the FPGA continues to work normally. This is pretty hard to use and the interface between the part being swapped and the rest of the circuit is rather tricky, so it has been use more for cool demos than actual products.
It is possible to have the equivalent to this with non Xilinx FPGAs by having several smaller ones connected to each other on a board. Then dynamic reconfiguration of one can happen while the others continue to work normally.
* Would it increase the complexity a lot to provide a linux-capable SoC as an additional chip? (OK, this could be a daughter board)
* "iCE40UP5K SG48, 98% utilized" <- isn't it a bit restrictive to start with such a low room for growth?
The main CPU is a Spartan7 XC7S50, which has plenty of space for things like crypto accelerator cores beyond the primary RISC-V CPU.
Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).
But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.
Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).
Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.
Luckily you can use an optimized ed25519 to implement ristretto255, which solves this problem :)
> enclosure’s length and thickness are are parameterized.
The iCE40UP5K will work with any IceStorm-based FOSS toolchain (including SymbiFlow) as well as Lattice's free first party Radiant tool (and I think also the older IceCube2 toolchain).
It's a little odd that they're different vendor parts / on different 1st party toolchains, but it does look like you could program everything through the FOSS tools, albeit probably missing a few features (Last I looked a couple of the special purpose blocks in both the Xilinx 7-series and the UltraPlus were not fully understood by the FOSS stuff; that may have changed).
I've been meaning to try Radiant, I teach some classes on top fo Vivado + Artix7 FPGA dev boards, and it's so much less awful than ISE (Xilinx's old toolchain) I'm still pleased with, but there are some nice, affordable iCE40-UltraPlus boards coming on the market, and if Radiant is less of a hassle (Vivado is a 25GB install and not _entirely_ beginner-friendly) I'd consider retooling.
How deep do you want to go down the rabbit hole? Are you capable of fabbing your own silicon?
if your asic if compromised in tranist, it's a total game over. if your fpga is compromised in transit, the attacker has to have some knowledge of target bitstream
it has been argued that by making it easy for end users to rearrange the bitstream, an fpga can be more secure than an asic
It is shortsighted to view making your own ASIC as less secure. The supply chain weaknesses exist whether or not you make your own hardware. Making your own hardware can potentially limit your exposure to systemic baked in vulnerabilities. Additionally, after-manufacture exploits (as in the NSA interdiction of Cisco router shipments) are easier for mass produced goods.
There are likely edge cases involving small, easier to bribe manufacturers, but I'm not sure you can make broad generalizations on that possibility alone.
It's great that Facebook/Apple/Google can securely manufacture devices, with a supply chain thats verifiable by them, but externally, TouchID's security amounts to "we're Apple, trust us". That's not good enough for the target market for Precursor.
I know? Your two points are really disjoint.
>so all there is in this space is "small, easier to bribe manufacturers".
I think the amount of people who will willingly take money for nefarious purposes is smaller than you think. I would worry more about misguided cooperation with law enforcement. See, for example, the case of the Russian trying to bribe a Tesla employee to install malware. There may be factors like the belief of the employee that the breach attempt would be caught, but it would be very easy to pass the employees actions off as a mistake.
My real point is that between large manufacturers that are likely to have moles or cooperate with law enforcement and smaller manufacturers that are less likely to have moles but may be easier to compromise in general, it's probably about even between them, maybe siding with smaller manufacturers depending on what you have available.
In any case you have trust issues with either one, so I don't see why pointing out "Trust us is not enough" is topical.
With a smaller manufacturer you are more likely to get in to see their facilities and can build a personal relationship. With a larger one that is likely impossible.
> We are also using the FPGA in Precursor to validate our SoC design, which will eventually give us the confidence we need to tape out a full-custom Betrusted ASIC, thereby lowering production costs while raising the bar on hardware security.
I'm defining "security" to include the ability of a device to keep a secret after it's been verified and provisioned. This is also known as "tamper resistance".
I'm defining "trustability" as the ability of one to draw the conclusion that the device in front of you is in fact the device you think it is. It's an essential pre-requisite for security, but it is not identical to "tamper resistance", which is probably what more people expect when they hear the word "security" (that is, security sounds more like a bullet proof vault than a correctly constructed system).
From the trustability standpoint, even a sophisticated technologist will typically have no evidence-based reason to trust any given chip, because they likely have no tools on hand that can verify its correct construction without simultaneously destroying the chip. For example, not many people have a ptychographic x-ray system at home.
On the other hand, you may have some reason to trust an FPGA, because with the tools in your home you can craft your own bitstreams and designs that incorporate countermeasures to potential exploits buried in the FPGA. It tips the balance of power from a "hands up I surrender" situation to a cat-and-mouse game. Furthermore, there is a limit to how deep the rabbit hole can go, because with sufficient countermeasures the circuitry required to backdoor the design without detection becomes larger than can fit within the raw size of the FPGA's silicon.
Thus, an FPGA is "more trustable" than an ASIC in the sense that there is any direct evidence-based reason at all for trusting it.
However, an FPGA is not necessarily more tamper-resistant than an ASIC. If your adversary has full physical possession of your device and has no regard to leaving it intact, then they have a number of venues to attack both the FPGA and the ASIC.
What this statement implies is that a properly designed ASIC will generally raise the bar on how hard it is to extract secrets compared to an FPGA, assuming an adversary with direct physical access to the device and no regard to evidence of tampering with the device.
More importantly, however, the ASIC will be cheaper. That is really the main point of that statement.
Another area that I've been thinking about, but I see you haven't written about here, is the issue of boot and IO. I would love to see IO systems greatly simplified, to the point where input devices are designed to just write measurement to memory on power on, and stop on power off. In the same way, devices periodically check a fixed memory region for something to write. If the input memory region was large enough, this would be a perfect opportunity for a poor-man's circular buffer of arbitrary size, which has lots of applications. Indeed, you could have explicitly zero copy use of input if you could guarantee that your process completes before the buffer is overwritten, which you can guarantee by just making it really big (or carefully tuning if you're memory constrained).
The goal of all of this is to embrace the modern era of computing which is NOT memory constrained at all, and to build computers that function more closely to their Platonic ideals. A system like yours seems to get the closest I've seen to this goal, modulo a few things mentioned above.
Cheers, and good luck (from a backer).
https://www.yokogawa.com/yjp/solutions/solutions/minimal-fab...
The image? Sure, could easily be backdoored, but that’s what open source is for; auditability.
Edit: FPGA silicon is kinda backdoored by definition thanks to JTAG configurability/readability. (Barring cases where keys are used.) So I think the really interesting thing would be addition of nefarious logic by the design tools.
Either the silicon, the synthesis software, or both could be compromised. Per leaked documents usually what gets attacked is random number generation, but there are more avenues I am sure.
You can usually turn off JTAG, but having JTAG or other debug interface not be permanently disabled is actually an exploit class.
To fight such an attack, the output of deterministic builds running on geographically dispersed systems with disparate stacks (physical, cloud, newly purchased, multiple OSs, etc.) may be compared before release.
The protected body of software should also include the firmware upload utilities.
Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
>Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
I like thinking about high-level threat models as much as the next guy, but these two statements seem to be at odds. Unless by "compromised units" you don't mean what I think you mean.
But I do not know if the Xilinx reversing effort supports the Xilinx chip. That project is in a much earlier state of development.
And I do have to wonder if an ecp5 (supported by trellis project) wouldn't have been able to do the job.