Project update 32 of 37
We have a potpourri of features and fixes for our last release of 2022. Here’s what’s in Xous 0.9.11.
The backup key protects your backups by encrypting the FPGA bitstream, which in turn contains your root keys. Users who have run "prepare backup" will have noted that the default backup key on the device has no entropy (it is all 0’s). This release has a Beta feature for key burning, supporting both BBRAM and eFuse flows. In order to use the feature, you’ll need to build a custom image with the argument
--feature efuse to unlock the menu item on the root menu.
The trade-offs of which key (eFuse or BBRAM) to use are nuanced. Please consider the following carefully when making your choice:
BBRAM keys are volatile keys that naturally reset to zero.
eFuse keys are permanent, one-time programmable keys
We are looking for people who are interested in testing the eFuse flow; let us know your interest through the Precursor Support channel or by sending a DM to bunnie.
While we have good confidence in the BBRAM flow, it’s difficult to do CI testing for the eFuse flow because the burning process is indelible; once the backup key has been fused, you can’t change it, and you can’t read it back out. Every test run is literally burning through FPGAs at a time when FPGAs have a two-year lead time.
Fortunately, I was able to resurrect a batch of pre-production devices for eFuse development, so no production devices were harmed by endian-ness bugs in fusing keys. Currently the eFuse process has been tested end to end without incident, so I feel confident in asking others to try it. However, out of an abundance of caution, I would like to be "on call" the first couple of times this happens, in case there is a problem.
Thanks to a heroic effort by @gsora, we now have a preferences manager. A number of settings that have accumulated in the root menu have migrated into the "Preferences" sub-menu, including things like WiFi setup, time, and time zone setting.
When you update, you will be prompted to re-enter your time zone and set the time, as the old setting is not automatically pulled into the new preferences setup.
Auto-backlight is also now on by default, so when a key is pressed the backlight will turn on for a default period of ten seconds. This can be disabled in the preferences sub-menu.
Reboot option in the main menu has also been changed to
Lock device, since these are functionally equivalent. This change was made because it’s assumed the more typical thing users want to do is lock their device; rebooting is the "securest" way to ensure the device is in a locked state as it unmounts all the PDDB Bases and zero-izes all of RAM as part of the reboot process. The device will also automatically put itself into sleep (or reboot if plugged into a computer) after three unsuccessful login attempts.
Folks who do password management the old-school way — perhaps in a text file or a spreadsheet — can now import to
vault using the CSV import flow with the vaultbackup-rs tool. The TL;DR is the passwords should be formatted into a CSV with the following header:
And then run through
vaultbackup-rs to transform this into a JSON file that can then be uploaded to your device using the same command a second time.
Note that each password entry is loaded into the device with an atomic write transaction that takes about a half second to complete, so it will take several minutes to upload a couple hundred entries (and there is currently no progress bar in the UX).
A lot of work was also done to improve the query performance password databases; query times were improved by about 2.5x. The journey was an interesting one; read more here if you like profiling tools and optimization. However, there are still a couple of seconds of lag when bringing up the password screen or refreshing it when hundreds of passwords are loaded. Most of the "easy wins" have been squeezed out; the long pole in the tent is now the heap allocator dealing with variable-length strings and heap fragmentation as the password database is assembled.
mtxcliMatrix Chat App
@tmarble has contributed
mtxcli to the app ecosystem. This is an https-secured chat client that can talk to a Matrix server. It is not E2EE (yet), but the transport is covered by TLS. You can load this on your device by building a custom image and specifying
mtxcli as one of the build arguments. Please note the app is not yet mature; there are stability and performance issues to be worked out.
Also thanks to @tmarble, we now have support for French localization. You can select this by picking a language option in
precursorupdater, with the
-l fr option.
svd2utra, and other core tools at the hardware abstraction layer
I continue to be impressed by how easy — and satisfying — it is to maintain Rust code. Most code bases start to feel scarier over time: as we scurry through well-trodden but dark hallways on our way to implement new features, we notice long-locked closet doors and suspect they are brimming with skeletons. We increasingly dread the day when they must be opened and cleared out.
Thankfully, Rust does not allow me to simply shove things into closets and lock the door. Every time I open one of these closets, I am pleasantly surprised to find everything neatly labelled. I’m able to shift the contents around into a more logical order, and immediately and confidently realize the causal consequences of the changes. It’s OK to forget how some things work, because Rust (and its suite of code analysis tools) can help remind you. Once you’re done tidying up the mystery closet, you almost want to install glass doors because everything just feels better.
This is in sharp contrast to some Python code I’ve been maintaining in parallel to do the USB update flows, where I’m struggling to even keep all the features in place because Python aggressively deprecates old versions. Over time, my Python code bases lose functionality because the underlying OS ceases to natively support a version of Python new enough to install the requisite libraries, leaving me in a no-win situation as a maintainer. Someday I will have to either remove the feature wholesale, or re-implement the feature within the four corners of my own code base; or I force the user to update their OS just to have access to one feature. However, that last option feels a bit like remodelling a house to fix a broken lightbulb.
That’s all for now. Until next time, happy hacking!