Tag Archives: firmware

Edit UEFI varstores

See end of post for an important update

UEFI firmware has a concept of persistent variables. They are used to control the boot order amongst other things. They are stored in non-volatile RAM on the system board, or for virtual machines in a host file.

When a UEFI machine is running you can edit these variables using various tools, such as Peter Jones’s efivar library, or the efibootmgr program.

These programs don’t actually edit the varstore directly. They access the kernel /sys/firmware/efi interface, but even the kernel doesn’t edit the varstore. It just redirects to the UEFI runtime “Variable Services”, so what is really running is UEFI code (possibly proprietary, but more usually from the open source TianoCore project).

So how can you edit varstores offline? The NVRAM file format is peculiar to say the least, and the only real specification is the code that writes it from Tianocore. So somehow you must reuse that code. To make it more complicated, the varstore NVRAM format is tied to the specific firmware that uses it, so varstores used on aarch64 aren’t compatible with those on x86-64, nor are SecureBoot varstores compatible with normal ones.

virt-efivars is an attempt to do that. It’s rather “meta”. You write a small editor program (an example is included), and virt-efivars compiles it into a tiny appliance. You then boot the appliance using qemu + UEFI firmware + varstore combination, the editor program runs and edits the varstore, using the UEFI code.

It works .. at least on aarch64 which is the only convenient machine I have that has virtualized UEFI.

Git repo: http://git.annexia.org/?p=virt-efivars.git;a=summary


After studying this problem some more, Laszlo Ersek came up with a different and better plan:

  1. Boot qemu with only the OVMF code & varstore attached. No OS or appliance.
  2. This should drop you into a UEFI shell which is accessible over qemu’s serial port.
  3. Send appropriate setvar commands to update the variables. Using expect this should be automatable.

Leave a comment

Filed under Uncategorized

Densha de gone

I enjoyed playing a Japanese import of Densha De Go (an accurate Shinkansen train simulator) on my old Nintendo Wii. I played this legally (albeit expensively) imported game using some other software called Wii Freeloader. Since Nintendo does not like people using software from outside the “right” places, “Freeloader” had to exploit a bug in the firmware to allow Densha de Go to play.

Today I upgraded the firmware on my Wii console.

I am no longer able to play Densha De Go at all. Nintendo have successfully covered all options and there is no way to play my legally purchased and imported software from other “regions” of the world.

So today I learned my lesson. Never absolutely never buy or get involved in proprietary software. Never buy anything ever again from Nintendo. Never buy another phone from Apple, or Microsoft, or any computer with proprietary software no matter how convenient it may seem in the short term.

Enough is enough.

If I bought the hardware, I want to do whatever I want with it.


Filed under Uncategorized