Happy holidays!

We have a potpourri of features and fixes for our last release of 2022. Here’s what’s in Xous 0.9.11.

Backup Key Provisioning now in Beta

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.

  • A key reset causes all data on the device to be instantly unusable
  • The device can be re-used by re-flashing a factory image and a new key using a JTAG cable
  • Pros:
    • Useful if you would rather lose data than have it in the wrong hands
    • A misplaced device will eventually zero-ize its keys once the battery is fully depleted
    • Key can be rotated in case of compromise
    • Instant secure erase by zero-izing the key
  • Cons:
    • Risk of unintentional data loss (power glitch or momentary battery disconnect leads to data loss)
    • You must charge the device roughly once every couple of months to retain the keys
    • Inconvenient and less secure provisioning: requires third-party hardware to burn (Raspberry Pi + Debug HAT - this is a limitation of the FPGA itself). This briefly exposes the key to the Raspberry Pi doing the burning.

• eFuse keys are permanent, one-time programmable keys

  • Once burned, they can never be updated
  • Pros:
    • Fully self-contained burning process - no external hardware required; no risk of key disclosure
    • No risk of data loss if the battery is disconnected or discharged
  • Cons:
    • Irreversible. If the key is compromised or lost, you cannot change it. You have to buy a new device.
    • If you lose the backup key and your device is bricked, the device is lost. You have to buy a new device.
    • Difficult to test, so the flow has less test coverage.
    • A lost device would retain its data even if the battery fully discharges

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.

Simplified Root Menu and Preferences Settings

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.

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

CSV Password Import

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:

site,username,password,notes

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.

mtxcli Matrix 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.

New Language: French

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.

Other Improvements

Bug fixes:

• Fixed bug in device auto-shutdown/reboot; COM/LLIO method deprecated as susres method does the correct sequencing. This should help with some of the "insert paperclip" scenarios after updating the SoC
• Updated VexRiscv core to the latest version. STATIC branch prediction enabled and slightly faster I$ gives a small performance bump. Also fixes a bug with cache flushing that was causing coherence problems with the PDDB
• @xobs fixed a tricky loader bug that was causing subtle issues with various build configurations
• Various infrastructure fixes contributed by @eupn and @jeandudey, relating primarily to utralib, svd2utra, and other core tools at the hardware abstraction layer
• Several infrastructure changes/improvements to how exported crates work

UX improvements:

• Wifi signal strength is rendered as bars, instead of as a numeric report of dBm (thanks to @gsora for the PR)
• System now provides user feedback about the boot and mount status as it comes up
• More GAM fixes to improve rendering performance on context switching and to prevent multiple defacements from stacking (especially on boot)

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!

-bunnie