Qubes fwupd upstream by macpijan · Pull Request #834 · linuxboot/heads

macpijan · 2020-09-15T06:15:50Z

How is heads currently versioned? In the QubesOS script https://github.com/3mdeb/qubes-fwupd/blob/master/src/qubes_fwupd_heads.py#L91 we check for the current version and want to download an update from LVFS only if the version is more recent. We can see that the latest tag is from 2017 though. We have used the LOCALVERSION field to inert the version information for testing purposes.

The Python script drops the update file to the boot partition. Then, the flash-gui.sh script was extended to look for updates there in the first place.

The update process is described here: https://github.com/3mdeb/qubes-fwupd/blob/master/doc/heads_udpate.md

tlaurion · 2020-09-15T14:31:10Z

@macpijan Heads is versioned per commit ID (as of now) which is inserted at build time under /etc/config
https://github.com/osresearch/heads/blob/master/Makefile#L105
https://github.com/osresearch/heads/blob/master/Makefile#L596

Let me know if we should change something

tlaurion · 2020-09-15T14:49:57Z

@macpijan I see that the script searches for a ROM inside a known path.
Maybe we should implement a hook inside of /boot integrity validation?

Normal boot codepath entry point for /boot integrity validation

verify_global_hashes() local fonction

check_config imported global fonction

So that if a new firmware is dropped in path, verify_global_hashes could see that the past ROM that was user signed changed, and then check ROM signature against heads imported distinguished distro key (oem_distro_keys instead)?

Asiderr · 2020-09-16T07:32:13Z

Heads is versioned per commit ID (as of now) which is inserted at build time under /etc/config

@tlaurion Currently we are parsing the Heads version from the fwupdmgr hwids:

https://github.com/fwupd/fwupd/blob/7fc7da3999a3bb0d7e75b4e72993783d82836329/src/fu-tool.c#L1424

Currently, the qubes-fwupd is looking for the line:

BiosVersion: CBET4000 <version> heads

The version number is set in the LOCALVERSION variable. If there is no version tag, it assumes that bios is older than the one that exists in the lvfs.

Let me know if we should change something.

In our case, the easiest to handle would be some release cycle with the version numbers. Every release should be uploaded to the lvfs.

tlaurion · 2020-09-23T13:52:06Z

@Asiderr can you pinpoint to experts, documentation so that we can move this forward?

My understanding here is that we have to change heads rolling release to a commited time based release, where CircleCI would need to push artifacts back into github, where measured matching (reproducible hashes for different hosts/OS builds) builds would be pushed.

I have no idea right now how to push that change forward, and do not have the rights over Heads repo to do such changes where @osresearch didn't replied to messages sent over slack on the matter after the opening of that PR.

Intuition says that changing manually the version under coreboot config for each board is not the way to go.
I'm clueless on what steps needs to be taken here so that

this first step is done (versioning)
then how those versioned artifacts would then be pushed back to github releases for that version, automatically.

Opened an issue a long time ago on that matter. Will edit when found again.

tlaurion · 2020-09-23T13:56:01Z

@Asiderr I also understand that (actions needed, in short)

some fwupd code needs to be upstreamed to fwupd @hughsie
some other qubesos related code needs to be upstreamed to QubesOS @marmarek
versioning scheme of heads needs to change and CIs configs changed to uploads versions are pushed back to github to be picked up and pushed to lvfs (@Asiderr + @osresearch + @macpijan discussion?)

Asiderr · 2020-09-25T16:59:38Z

@tlaurion

can you pinpoint to experts, documentation so that we can move this forward?

The latest documentation about the heads update can be found here:
https://github.com/3mdeb/qubes-fwupd/blob/master/doc/heads_udpate.md

Here is the class that handles the heads update process:
https://github.com/3mdeb/qubes-fwupd/blob/master/src/qubes_fwupd_heads.py

Intuition says that changing manually the version under coreboot config
for each board is not the way to go.

You're right, it should be automated somehow.

some fwupd code needs to be upstreamed to fwupd
some other qubesos related code needs to be upstreamed to QubesOS

The source code of the wrapper should be placed in the fwupd/fwupd repo.
Packing scripts should be upstreamed to the QubesOS.

versioning scheme of heads needs to change and CIs configs changed to uploads
versions are pushed back to github to be picked up and pushed to lvfs

That's right.

tlaurion · 2020-10-04T22:11:17Z

@Asiderr

The source code of the wrapper should be placed in the fwupd/fwupd repo.
Packing scripts should be upstreamed to the QubesOS.

You do the PRs?

Asiderr · 2020-10-06T08:58:20Z

@tlaurion We're discussing the way of the upstream now:
https://groups.google.com/g/fwupd/c/u5JEIQO_rp8
Once the PRs are created, I'll link them.

tlaurion · 2020-10-18T14:30:06Z

linked to #839 #859

tlaurion · 2020-10-18T17:27:19Z

@Asiderr important question on FWUPD #859 (comment)

tlaurion · 2020-10-21T15:21:22Z

@Asiderr

So following merge of https://github.com/osresearch/heads/pull/859/files#diff-18936189b28399cf48703d0c1ec1df33e57c559de2a12f4438be00e6813bdb68R40-R41

We now have, injected in coreboot config automatically for each built board:

And the filenames for final produced rom images can be seen, and downloaded for testing of FWUPD usage of CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME here in ~2 hours from now (since heads modules changes, triggering a new CicrlceCI build only on musl-cross-make CircleCi cache)

Any comment?
Next steps will happen under #571 to:

Determine next steps to create releases
Build artifacts and be able to compare hashes.txt for same board from different hosts (docker images)
Define a process to confirm reproducibility from there
Define how LVFS images will get uploaded from there
Any other consideration i'm missing here.

Asiderr · 2020-10-27T12:56:25Z

@tlaurion Naming and versioning look fine and I'll include the changes in the wrapper.

Define how LVFS images will get uploaded from there

For testing purposes, I'll put manually the cabinet archives on the LVFS. But it's temporary and we have to ask @hughsie if there is any possibility to automate the upload process (I don't see any information in the documentation on this topic).

hughsie · 2020-10-27T13:03:05Z

is any possibility to automate the upload process

We have robot users that are able to upload automatically; Dell uses this to automate firmware being uploaded to the LVFS as it's built in their pipeline. https://gitlab.com/fwupd/lvfs-website/-/blob/master/contrib/example.py has an example upload if that helps.

tlaurion · 2020-12-02T23:08:17Z

@macpijan Any news?

macpijan · 2020-12-08T09:35:37Z

@tlaurion Sorry for the delay. Our plan is to go back to it next week and finish by the end of the year.

tlaurion · 2021-03-23T03:55:00Z

@macpijan any updates and links would be greatly appreciated!

macpijan · 2021-03-23T08:34:35Z

@Asiderr Please provide links

Asiderr · 2021-03-24T12:13:08Z

@tlaurion @macpijan The qubes-wrapper has been merged recently in the fwupd tree:
fwupd/fwupd#2710
I can see that #789 is solved, thus we can swap to the Qubes R4.1.
Now, we should focus on the release process, and we should bring the Heads binaries to the LVFS.

tlaurion · 2021-07-25T21:00:34Z

@Asiderr @macpijan There is QubesOS/qubes-issues#6792 blocking while a test rom seem to resolve all sandy/ivy bridge issues.

I now have a testing platform to test QubesOS 4.1 deployment on.

Contacted @osresearch to have current Heads repo on a release, with binaries coming from CircleCI uploaded to that github release following https://circleci.com/blog/publishing-to-github-releases-via-circleci/

tlaurion · 2021-12-07T03:32:03Z

Ping @osresearch

Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>

Asiderr · 2022-06-14T15:03:53Z

@tlaurion I updated flash-gui.sh and now it supports current Heads versioning (#859). Also, I added necessary changes to the fwupd (fwupd/fwupd#4745).

I created a Qubes OS CI in fwupd that generates binary packages, and we are currently discussing the possibility of upstreaming to YUM and APT (fwupd/fwupd#4744).

The last thing we need to think about is the release process of the Heads. The Heads binaries must be uploaded to the LFVS.

hughsie · 2022-06-14T18:06:42Z

The Heads binaries must be uploaded to the LFVS

Can you use the API? https://lvfs.readthedocs.io/en/latest/upload.html#automatic-uploads

tlaurion

@Asiderr: some concerns about content of updates dir and lack of verification of that content prior of proposing end-user for firmware upgrades

tlaurion · 2022-06-22T19:45:21Z

+      # check if fwupd updates exist
+      if ls /boot/updates/*/*.rom > /dev/null 2>&1; then
+        if (whiptail --title 'Flash the BIOS with a new ROM' \
+          --yesno "A ROM detected in the /boot/updates directory.\n\nDo you want to proceed?" 16 90) then
+          find /boot/updates ! -path '*/\.*' -type f -name '*.rom' | sort > /tmp/filelist.txt


Question from what will be dropped under /boot/updates//

Do we have a hashes.txt coming from the builds?

Is that hashes.txt detached signed with OEM key and provided as well?

Should we think of adding a OEM directory to add public keys under OEM directory?

Should we add validation prior of proposing the ROM to the user and only propose if valid?

The same logic then booting from ISO could easily be borrowed here, where ISO is validated against a seperate gpg --home= instance relative to known distro keys

Thoughts?

Otherwise, any rom being dropped under /boot/updates would be considered a valid firmware update.
@MrChromebox

Otherwise, any rom being dropped under /boot/updates would be considered a valid firmware update.
@MrChromebox

that's really no different from what we do now from USB

@MrChromebox well, right now upgrading from USB considered intentional. Now anything pushing updates to that directory would leave user thinking that firmware is authentic and valid and would prompt the user to flash without further validation from Heads.

Implementation on the Heads side isn't completed yet, so stable release can't be updated yet. There is a work in progress version at linuxboot/heads#834. So, add a note that it isn't fully supported yet. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

tlaurion · 2026-03-05T19:55:59Z

I think boot path should be /boot/$(BRANDING)-firmware/* to pickup here? @macpijan ?

move flash-gui.sh integrity check logic to flash.sh (Move zip hash verification logic from flash-gui.sh to flash.sh #1593)
since /boot integrity changed, we should ask to delete zip file and display /boot actual free space
- if zip file deleted, no need to update /boot integrity
- if zip kept, update /boot integrity after showing integrity summary for confirmation (other files changed)
on next boot updating TOTP/HOTP will guide for resealing TPM DUK properly per Busybox's fdisk calls warns on >2tb disks #1883

macpijan mentioned this pull request Sep 15, 2020

flash-gui.sh: Handle qubes-fwupd updates 3mdeb/heads#1

Closed

tlaurion mentioned this pull request Oct 4, 2020

Maintain actual CI to confirm reproducibility of roms across distributions #571

Closed

This was referenced Oct 18, 2020

Inject Heads version string into coreboot LOCALVERSION... #859

Merged

Add git hash and tags for versioning #839

Closed

tlaurion mentioned this pull request Dec 2, 2020

Overcomming space limitations for fancy features #818

Open

Asiderr force-pushed the qubes-fwupd-upstream branch 2 times, most recently from 8f4051c to a7d216b Compare June 14, 2022 11:34

flash-gui.sh: handle fw updates from boot partition

97851b9

Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>

Asiderr force-pushed the qubes-fwupd-upstream branch from a7d216b to 97851b9 Compare June 14, 2022 11:36

tlaurion reviewed Jun 22, 2022

View reviewed changes

tlaurion mentioned this pull request Oct 22, 2023

Distribute heads updates via https://fwupd.org/ Nitrokey/heads#26

Closed

tlaurion mentioned this pull request Jan 18, 2024

Move zip hash verification logic from flash-gui.sh to flash.sh #1593

Open

Asiderr mentioned this pull request Dec 2, 2024

fwupd support #613

Open

tlaurion added the feature freeze 2026-04 label Mar 5, 2026

tlaurion removed the feature freeze 2026-04 label May 12, 2026

Uh oh!

Uh oh!

Conversation

macpijan commented Sep 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Sep 15, 2020

Uh oh!

tlaurion commented Sep 15, 2020

Uh oh!

Asiderr commented Sep 16, 2020

Uh oh!

tlaurion commented Sep 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Sep 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Asiderr commented Sep 25, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Oct 4, 2020

Uh oh!

Asiderr commented Oct 6, 2020

Uh oh!

tlaurion commented Oct 18, 2020

Uh oh!

tlaurion commented Oct 18, 2020

Uh oh!

tlaurion commented Oct 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Asiderr commented Oct 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hughsie commented Oct 27, 2020

Uh oh!

tlaurion commented Dec 2, 2020

Uh oh!

macpijan commented Dec 8, 2020

Uh oh!

tlaurion commented Mar 23, 2021

Uh oh!

macpijan commented Mar 23, 2021

Uh oh!

Asiderr commented Mar 24, 2021

Uh oh!

tlaurion commented Jul 25, 2021

Uh oh!

tlaurion commented Dec 7, 2021

Uh oh!

Asiderr commented Jun 14, 2022

Uh oh!

hughsie commented Jun 14, 2022

Uh oh!

tlaurion left a comment

Choose a reason for hiding this comment

Uh oh!

tlaurion Jun 22, 2022

Choose a reason for hiding this comment

Uh oh!

tlaurion Jun 22, 2022

Choose a reason for hiding this comment

Uh oh!

MrChromebox Jun 22, 2022

Choose a reason for hiding this comment

Uh oh!

tlaurion Jun 24, 2022

Choose a reason for hiding this comment

Uh oh!

tlaurion commented Mar 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

macpijan commented Sep 15, 2020 •

edited

Loading

tlaurion commented Sep 23, 2020 •

edited

Loading

tlaurion commented Sep 23, 2020 •

edited

Loading

Asiderr commented Sep 25, 2020 •

edited

Loading

tlaurion commented Oct 21, 2020 •

edited

Loading

Asiderr commented Oct 27, 2020 •

edited

Loading