To upgrade Insurgo Privacybeast to 4.1 or not?

Hi Again @Insurgo

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

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.

2 Likes

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.

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

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

1 Like

Done.

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

Bumping for visibility.

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

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?

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:

  1. Backup Q4.0 Qubes/Templates to external storage How to back up, restore, and migrate | Qubes OS
  2. 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.
  3. 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.
  4. Install Qubes Q4.1 following Step 4 - Installing Qubes and other OSes - Heads - Wiki
  5. Update dom0/Templates.
  6. Restore needed Qubes.
  7. Install additionally needed software under Templates.
2 Likes

@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 · osresearch/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.16-651-gd083317fae 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.

1 Like

@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 · osresearch/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.16-651-gd083317fae 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.

1 Like

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?

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:

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

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

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:

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 :slight_smile:

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.

@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? :slight_smile:

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

1 Like

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