To upgrade Insurgo Privacybeast to 4.1 or not?

golden_jar56 · April 8, 2022, 6:18pm

Yes, I am completely aware that I would have to share the passphrases in order for the shipping option to work. While not ideal of course, I think it is the best of the available options.

Lets break this down. Of the 3 possibilities (1.Trying to upgrade on my own, 2. Staying on 4.0 that the laptop shipped with, or 3. Sending it back to you with all necessary passphrases/secrets included) I genuinely feel option 3 poses the least risk. You are obviously trustworthy and while there is always the possibily of interception or compromise coming from the shipping part of the process, the likelihood of that is MUCH lower than the risk I would be taking by trying (and most probably failing completely) option 1 to perform the upgrade myself, and option 2 is already running a high risk as we speak, since things like whonix have already marked 4.0 as obsolete.

As proposed in my last comment, if you believe there is a “dumbed-down” guide releasing soon, I am happy to wait and test with that, but if it is going to be a collaborative project between yourself and members here, and encompasing everything from HEADS, to resealing to backing up, installing and upgrading Qubes, that may take substantial time to write. I guess a potential 4th option would be inquiring if you buy back previously shipped machines (obviously I wouldnt get the price I paid back, but would just want to add whatever extra amount was necessary to essentially trade it in for a new one that ships with 4.1 already installed) These options definitely are out of the ordinary, but I am just trying to be creative in finding a feasible solution to the problem that works for, and is within the capabilities of, everyone

It turns out someone seems to have taken a picture of me attempting to perform the upgrade. I have included it below.

well-theres-your-problem-rave-ho-idea-what-im-doing-memes-6922d79a742889c8-5b15224cbbb56389

Sven · April 9, 2022, 12:04am

This is not a real issue if you think about what the list is for: informing a purchase for a non-technical user. In this context there are only two scenario:

a) the user bought the laptop with R4.0 at which point it was certified and on the community list for R4.0 … and it just works

b) the user bought the laptop with R4.1 … same deal

Nothing in the list promises a “just works” upgrade experience. However, R4.0 users can run an in-place upgrade to R4.1 and that does not require a firmware upgrade.

I can also imagine Insurgo and NitroPad offering a service where you backup your data, wipe the machine and send it back to them. They could then “refurbish” the machine by installing R4.1 and go through the same process in sealing it and shipping it back to you just like a new purchase. Obviously they will charge for that service.

fsflover · April 9, 2022, 8:45am

You are right about the new purchases of course. However, I was misled by this table assuming that if it’s certified, you can always install Qubes OS 4.1 without any workarounds. For this reason, I think, there should be a link to here from the table.

golden_jar56 · April 9, 2022, 7:04pm

Also, just wanted to say a big thank you to Sven and FSFLover. Did not mean to neglect either you. I appreciate the input and advice you provided, and hopefully we can all get some sort of workable answer to this problem, as I am sure there are many in the exact same boat but dont want to reach out or are scared to do so. So thanks to everyone who is helping on this

Sven · April 9, 2022, 9:30pm

@fsflover I am thinking about how to do this best without complicating the table and without linking to an actual discussion.

Instead I’d like to create an authoritative sentence or two about R4.1 introducing LUKS2 headers which in turn require a certain version of coreboot. This does apply to the certified laptops but also other laptops based on coreboot including Purism products.

Sven · April 14, 2022, 1:22am

Done.

golden_jar56 · April 14, 2022, 11:26pm

Much thanks to everyone for the help here. Do we have any idea on an easy to follow guide for this whole process, or exactly how this can be done by normal users? Perhaps this is more suited for @Insurgo , but I am grateful for any and all help

golden_jar56 · April 19, 2022, 3:36pm

Bumping for visibility.

Demi · April 19, 2022, 4:26pm

I don’t think it is specifically the LUKS2 headers that matter here, but rather the information used to unseal them.

Demi · April 19, 2022, 4:28pm

Why does the command line need to be used for this? That seems like it could be handled automatically via a package of some sort. And what is the command that needs to be run?

Insurgo · April 19, 2022, 5:31pm

Heads is a rolling release.

I would love more participation/review/comments, most importantly on the clarity of the documentation available at https://osresearch.net (where issues/PR happen under GitHub - osresearch/heads-wiki: Documentation for the Heads firmware project).

A pinned issue is opened at Issues · osresearch/heads-wiki · GitHub pointing to Document where to find/download latest CircleCI builds · Issue #88 · osresearch/heads-wiki · GitHub for users that do not want to build Heads themselves (Building Heads is another story altogether. Building issues are often opened because users want to build from so many different Linux distributions, where CircleCI builds on Debian-11 docker).

Fresh install of Qubes 4.1 is still the recommended path.

So basically @golden_jar56 @fsflover:

Backup Q4.0 Qubes/Templates to external storage How to back up, restore, and migrate | Qubes OS
Follow/comment Document where to find/download latest CircleCI builds · Issue #88 · osresearch/heads-wiki · GitHub to download latest ROM from github latest commit (applies directly to PrivacyBeast, without need to externally flash). Verify hashes.
Download Q4.1 ISO and detached signature to ext3/ext4 formatted USB thumb drive. Integrity/authenticity validation of the ISO will be verified prior of launching the installer.
Install Qubes Q4.1 following Step 4 - Installing Qubes and other OSes - Heads - Wiki
Update dom0/Templates.
Restore needed Qubes.
Install additionally needed software under Templates.

Insurgo · April 19, 2022, 5:37pm

@Demi :

Heads packaged cryptsetup1 initially. To have support for TPM released Disk encryption key, cryptsetup2 needs to be in the firmware, you are right. The user could theoretically still boot their laptop by typing their LUKS disk encryption key passphrase. But they could not install Q4.1 without having done the firmware upgrade first, read below on the whys.

@Sven The firmware update is not only for that LUKS2 support, but to resolve graphical glitches that were not permitting Qubes 4.1 graphic installer to be launched without a coreboot upgrade (coreboot+vbt). Otherwise, users attempting to install Q4.1 would face QubesOS 4.1 installer doesn't boot on sandy/ivy bridge (xx20/xx30) · Issue #789 · linuxboot/heads · GitHub graphical glitches, and Qubes installer just fails after a while, trying to work in text-based version which is not aimed to be functional under Qubes even today.

Insurgo · April 19, 2022, 5:58pm

Unfortunately, this is why things are complicated, since how Heads was deployed before Maximized builds existed (legacy boards).

I can try to summarize here again real short. Initially, Heads was aimed to not interfere with ME. Since the Intel Firmware Descriptor is normally locked, and the BIOS region is normally protected, Heads and Skulls required an external initial flash of the 4mb top SPI chip present in xx30 boards (the X230 was the first board to land under Heads).

Neither Heads nor Skulls required the end user to do anything with the 8mb bottom SPI flash. Still today, legacy boards do not expect the user to have neither unlocked the IFD or have neutered ME to take advantage of the freed space there. So Skulls and Heads (x230-flash) prepared 4mb roms to be flashed to the top SPI, and then flash internally the 7mb bios region, respecting the BIOS region defined under IFD.

The reasoning of this comes from the alignment of the BIOS region, which is spanning across the two SPI chips. See the flash layout here: Lenovo Ivy Bridge series — coreboot 4.22-679-gcc2ab49525 documentation

So to unlock IFD and neuter ME, the 8mb chip needed to be backuped and those instructions needed to be followed Cleaning Intel Management Engine | Heads - Wiki. ME was neutered, consequently, but the ME freed space was not made available to the BIOS region. The only way to do that is to also change the IFD with a smaller ME region matching its size, and the BIOS region expended (maximized) to take advantage of the freed ME space (bringing the BIOS region available space from 7mb to 11.5mb). This is what Maximized boards are.

1vyrain project landed, and was able to chainload exploits to bypass BIOS protections, mainly from S3 resume path vulnerabilities to unlock the BIOS region and be able to flash 4mb ROM images (Heads x230-flash and Skulls), permitting the end user to then flash the 7mb BIOS region contained under the invalid 12MB image (x230 legacy rom does not contain a valid IFD and is only flashing the BIOS region defined under the IFD). But it is not possible to unlock IFD nor ME regions internally. An initial external flashing of an unlocked IFD and ME region is required.

The PrivacyBeast shipped with IFD unlocked (as opposed to the NitroPad in the past). The PrivacyBeast permits users to upgrade to maximized boards, internally, but with a manual flashrom invocation, since maximized roms contains a valid IFD, a valid neutered ME and a valid GBE region. And because the ME region and IFD regions are unlocked.

So a PrivacyBeast owner can move away from legacy to maximized roms, manually upgrading once from the recovery shell by doing:

mount-usb
flashrom --force --noverify-all -p internal -w /media/PathToMaximizedRom.rom

Otherwise, the GUI will try to overwrite the 7mb BIOS region with a 11.5 BIOS region, which of course would result in a brick

All future firmware upgrades will flash the whole 12mb rom internally from the GUI. But the initial upgrade needs to be manual, which floods my support channels.

fsflover · April 19, 2022, 6:51pm

@Insurgo
I see that you updated the above posts. Some people, including some core developers, are interacting with this forum via email. They do not receive the edits made after 10 minutes. For this reason, it’s better to make a new post, not update the old one (and/or use quotations like I do below).

Here are your edited posts for them

@Demi :

Heads packaged cryptsetup1 initially. To have support for TPM released Disk encryption key, cryptsetup2 needs to be in the firmware, you are right. The user could theoretically still boot their laptop by typing their LUKS disk encryption key passphrase. But they could not install Q4.1 without having done the firmware upgrade first, read below on the whys.

@Sven The firmware update is not only for that LUKS2 support, but to resolve graphical glitches that were not permitting Qubes 4.1 graphic installer to be launched without a coreboot upgrade (coreboot+vbt). Otherwise, users attempting to install Q4.1 would face QubesOS 4.1 installer doesn't boot on sandy/ivy bridge (xx20/xx30) · Issue #789 · linuxboot/heads · GitHub graphical glitches, and Qubes installer just fails after a while, trying to work in text-based version which is not aimed to be functional under Qubes even today.

Unfortunately, this is why things are complicated, since how Heads was deployed before Maximized builds existed (legacy boards).

I can try to summarize here again real short. Initially, Heads was aimed to not interfere with ME. Since the Intel Firmware Descriptor is normally locked, and the BIOS region is normally protected, Heads and Skulls required an external initial flash of the 4mb top SPI chip present in xx30 boards (the X230 was the first board to land under Heads).

Neither Heads nor Skulls required the end user to do anything with the 8mb bottom SPI flash. Still today, legacy boards do not expect the user to have neither unlocked the IFD or have neutered ME to take advantage of the freed space there. So Skulls and Heads (x230-flash) prepared 4mb roms to be flashed to the top SPI, and then flash internally the 7mb bios region, respecting the BIOS region defined under IFD.

The reasoning of this comes from the alignment of the BIOS region, which is spanning across the two SPI chips. See the flash layout here: Lenovo Ivy Bridge series — coreboot 4.22-679-gcc2ab49525 documentation

So to unlock IFD and neuter ME, the 8mb chip needed to be backuped and those instructions needed to be followed Cleaning Intel Management Engine | Heads - Wiki. ME was neutered, consequently, but the ME freed space was not made available to the BIOS region. The only way to do that is to also change the IFD with a smaller ME region matching its size, and the BIOS region expended (maximized) to take advantage of the freed ME space (bringing the BIOS region available space from 7mb to 11.5mb). This is what Maximized boards are.

1vyrain project landed, and was able to chainload exploits to bypass BIOS protections, mainly from S3 resume path vulnerabilities to unlock the BIOS region and be able to flash 4mb ROM images (Heads x230-flash and Skulls), permitting the end user to then flash the 7mb BIOS region contained under the invalid 12MB image (x230 legacy rom does not contain a valid IFD and is only flashing the BIOS region defined under the IFD). But it is not possible to unlock IFD nor ME regions internally. An initial external flashing of an unlocked IFD and ME region is required.

The PrivacyBeast shipped with IFD unlocked (as opposed to the NitroPad in the past). The PrivacyBeast permits users to upgrade to maximized boards, internally, but with a manual flashrom invocation, since maximized roms contains a valid IFD, a valid neutered ME and a valid GBE region. And because the ME region and IFD regions are unlocked.

So a PrivacyBeast owner can move away from legacy to maximized roms, manually upgrading once from the recovery shell by doing:

mount-usb
flashrom --force --noverify-all -p internal -w /media/PathToMaximizedRom.rom

Otherwise, the GUI will try to overwrite the 7mb BIOS region with a 11.5 BIOS region, which of course would result in a brick

All future firmware upgrades will flash the whole 12mb rom internally from the GUI. But the initial upgrade needs to be manual, which floods my support channels.

Demi · April 19, 2022, 7:20pm

Otherwise, the GUI will try to overwrite the 7mb BIOS region with a 11.5 BIOS region, which of course would result in a brick

That’s a GUI bug. Is there a reason that the GUI cannot do the steps you mentioned?

Insurgo · April 19, 2022, 8:19pm

It’s not a GUI bug. Technically, board configurations declare how flashrom is to be called in the future for the next firmware upgrade. This is why upgrading from legacy to maximized boards needs to be done from recovery shell, once. I feel we are complexifying things (technical speaking mixed with worried users doesn’t seem to help.)

This is defined at build time and exported under initrd under /etc/config (which contains git commit and other exported variables per board configuration). The GUI (actually flash.sh script) will flash the firmware following what is configured to be used.

For legacy boards, only the IFD BIOS region is expected to be touched by an upgrade:

github.com

osresearch/heads/blob/41847f5cd22dc09e7765089c8818674a7d1fa489/boards/x230/x230.config#L59

      
        
            #SSH server (requires ethernet drivers, eg: CONFIG_LINUX_E1000E)
            CONFIG_DROPBEAR=n
            
            
export CONFIG_BOOTSCRIPT=/bin/gui-init
            export CONFIG_BOOT_REQ_HASH=n
            export CONFIG_BOOT_REQ_ROLLBACK=n
            export CONFIG_BOOT_KERNEL_ADD="intel_iommu=on intel_iommu=igfx_off"
            export CONFIG_BOOT_KERNEL_REMOVE="quiet"
            export CONFIG_BOOT_DEV="/dev/sda1"
            export CONFIG_BOARD_NAME="Thinkpad X230"
            export CONFIG_FLASHROM_OPTIONS="--force --noverify-all -p internal --ifd --image bios"
            
            
# This board has two SPI flash chips, an 8 MB that holds the IFD,
            # the ME image and part of the coreboot image, and a 4 MB one that
            # has the rest of the coreboot and the reset vector.
            #
            # Only flashing to the bios region is safe to do. The easiest is to
            # flash internally when the IFD is unlocked for writing, and x230-flash
            # is installed first.

Where for maximized boards, flashrom is expected to flash the whole combined 12mb opaque SPI chips (8mb+4mb):

github.com

osresearch/heads/blob/41847f5cd22dc09e7765089c8818674a7d1fa489/boards/x230-maximized/x230-maximized.config#L62

      
        
            #SSH server (requires ethernet drivers, eg: CONFIG_LINUX_E1000E)
            CONFIG_DROPBEAR=y
            
            
export CONFIG_BOOTSCRIPT=/bin/gui-init
            export CONFIG_BOOT_REQ_HASH=n
            export CONFIG_BOOT_REQ_ROLLBACK=n
            export CONFIG_BOOT_KERNEL_ADD="intel_iommu=on intel_iommu=igfx_off"
            export CONFIG_BOOT_KERNEL_REMOVE="quiet"
            export CONFIG_BOOT_DEV="/dev/sda1"
            export CONFIG_BOARD_NAME="Thinkpad X230-maximized"
            export CONFIG_FLASHROM_OPTIONS="--force --noverify-all -p internal"
            
            
# xx30-*-maximized boards require of you initially call one of the
            #  following to have gbe.bin ifd.bin and me.bin
            #  - blobs/xx30/download_clean_me.sh
            #     To download Lenovo original ME binary, neuter+deactivate ME, produce
            #      reduced IFD ME region and expanded BIOS IFD region.
            #  - blobs/xx30/extract.sh
            #     To extract from backuped 8M (bottom SPI) ME binary, GBE and IFD blobs.
            #
            # This board has two SPI flash chips, an 8 MB that holds the IFD,

CONFIG_FLASHROM_OPTIONS is then used in the flash.sh script, called by flash-gui.sh to know how to communicate with SPI chips:

github.com

osresearch/heads/blob/41847f5cd22dc09e7765089c8818674a7d1fa489/initrd/bin/flash.sh#L55

      
        
                fi
                # persist PCHSTRP9 from flash descriptor
                if [ "$CONFIG_BOARD" = "librem_l1um" ]; then
                  echo "Persisting PCHSTRP9"
                  flashrom $CONFIG_FLASHROM_OPTIONS -r /tmp/ifd.bin --ifd -i fd >/dev/null 2>&1 \
                  || die "Failed to read flash descriptor"
                  dd if=/tmp/ifd.bin bs=1 count=4 skip=292 of=/tmp/pchstrp9.bin >/dev/null 2>&1
                  dd if=/tmp/pchstrp9.bin bs=1 count=4 seek=292 of=/tmp/${CONFIG_BOARD}.rom conv=notrunc >/dev/null 2>&1
                fi
            
            
    flashrom $CONFIG_FLASHROM_OPTIONS -w /tmp/${CONFIG_BOARD}.rom \
                || die "$ROM: Flash failed"
              fi
            }
            
            
if [ "$1" == "-c" ]; then
              CLEAN=1
              READ=0
              ROM="$2"
            elif [ "$1" == "-r" ]; then
              CLEAN=0

So in this case of legacy to maximized ROM upgrade path, the end-user has to explicitly, and manually, tell flashrom to flash the whole 12mb combined 8mb+4mb SPI chips (not only the BIOS region):

flashrom --force --noverify-all -p internal -w /path/to/12mb.rom

As opposed to using per board declared CONFIG_FLASHROM_OPTIONS in firmware which otherwise would only flash the ifd defined BIOS region with something too big to fit in it, which would happen otherwise since flashrom options are set to do so for legacy boards:

--ifd --image bios

Again, moving from legacy to maximized board is only possible if IFD and ME regions were unlocked on initial external flash, which is the case here with the PrivacyBeast.

So upgrading the firmware to maximized builds is possible and recommended on the PrivacyBeast. It requires the user to download the firmware, verify the hashes, put the rom on a USB dongle, go to recovery shell and call flashrom as written.

Qubes community (@fsflover @golden_jar56 : How can I make the following guides clearer for you to follow:

Firmware upgrade guide: Prerequisites for Heads - Heads - Wiki
Qubes OS Q4.1 install guide over Heads: Step 4 - Installing Qubes and other OSes - Heads - Wiki clearer?
What makes you anxious? And most importantly, where that documentation should be clearer for you to be able to follow it?

As said previously, more technical blog posts have been written and followed by customers who contacted me directly, hosted over ZeroNet and accessible through clearnet proxy here: https://zerolink.ml/1DMb3CV66qZPwJqkgm4z12nu8BrAwDoD4g/?Post:57

Let me help you help me

Demi · April 19, 2022, 8:21pm

I still think this is something that should be handled by the GUI, even though it requires a special case in the code. Users expect the GUI to Just Work, even if it needs to go through contortions to do so.

Insurgo · April 19, 2022, 8:29pm

@Demi you cannot change the ROM flashrom statement magically. And implementing the change you are talking about would also require a firmware upgrade, so that GUI change would deal with the new logic, which would only be applied for the next firmware upgrade. Right?

Demi · April 19, 2022, 8:30pm

Ah, I thought that the GUI ran in the OS. I did not know that the GUI was part of the firmware.

golden_jar56 · April 30, 2022, 10:50pm

@Insurgo

Appreciate the attempts to try to help. Unfortunately, there is simply no way for me to perform the upgrade without messing something up. I dont feel comfortable using qubes while its outdated, and the likelyhood of compromising the entire machine by messing up the upgrade myself is even greater than that. I am afraid I will simply have to retire my privacybeast completely for the foreseeable future.

If at some point either “selling” my current privacybeast back to you and purchasing a new one with 4.1 already instaed, or simply mailing my current laptop back and paying for the upgrade service on it is an option, please be sure to let me know, I would be very interested in either option.