Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fwupd support #613

Open
tlaurion opened this issue Oct 8, 2019 · 15 comments
Open

fwupd support #613

tlaurion opened this issue Oct 8, 2019 · 15 comments

Comments

@tlaurion
Copy link
Collaborator

tlaurion commented Oct 8, 2019

No description provided.

@tlaurion tlaurion changed the title Fwupd support fwupd support Oct 8, 2019
@tlaurion
Copy link
Collaborator Author

tlaurion commented Aug 1, 2020

@pietrushnic :)

@pietrushnic
Copy link

@tlaurion could you be more specific? We working on NLNet milestone and @Asiderr recently reported the status here:
https://blog.3mdeb.com/2020/2020-07-14-qubesos-fwupd-core/

I believe there may be even more now. @Asiderr please provide feedback here and where to look for some information on how things going on. Maybe community can help with updates from heads perspective.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Aug 3, 2020

The goal was to trace developments 😃

@Asiderr
Copy link

Asiderr commented Aug 3, 2020

@tlaurion You will get the latest information about the progress from the project repository: qubes-fwupd. In addition to the status shown in the blog post, we have added a qubes-builder installing method. We are targeting the 4.1 version of the Qubes and during the distro installation under the heads and I've got the same issue as presented here:
#789

@tlaurion
Copy link
Collaborator Author

tlaurion commented Aug 3, 2020

I was expecting 116787f to fix it but it doesn't.

@tlaurion
Copy link
Collaborator Author

Quick note. This could easily be done (3-5h max) if logic of flash-gui.sh which checks if tgz or zip was moved to flash.sh, and if hashes mismarch of /boot reported there was a zip tgz dropped under /boot/fwup, ask user if he intended to upgrade firmware. If so, flash keeping settings, if not, propose to delete that changed file. If we flash, that new file is now part of detached signed boot hashes and verified on each boot. Maybe think about a maximum number of zio/tgz files matching board name only, and only propose file âmes that regex contains board name to make sure simili advanced users do not shoot themselves in the leg flashing another board's rom by error.

This workflow would propose to flash anytjing new being under fwupd dir, but not old ones per /boot integrity check, and pavé the way to beta channels as well, and help the testing workflow where it's possible to copy files to dom0 from dom0's /boot, where moving files is trivial, but where current workflow requires unzipping the file, where moving logic from flash-gui.sh to flash.sh would facilitate this, plus make sure of rom integrity per Ci produced roms which includes SHA256 inside of them, same for tgz(talos).

Would also be nice to have revert capability in case internal flashing failed for whatever reason, like attempt to flash something that is write protected. Offering auto revert to take a rom backup before flashing the new one with cbfs injected files as we currently do would safeguard against bricks in case of wp regions, including partial write protected regions for bootblock between coreboot versions which might change the bootblock or its size: a write op would fail because there is a change, where flashing the backup woukd succeed and prevent a brick.

@pietrushnic
Copy link

So you are saying Heads does not support fwupd? I thought it was implemented as part of Qubes OS integration.

I agree with your description of how it should work, but what is missing? Integrating it would make the lives of Dasharo (coreboot+Heads) users less miserable, so it would be a good improvement. We also think we should discuss when it can be done.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Qubesos support for fwupd is done, Heads is missing this PR to pick up correctly files dumped under /boot when heads firmware upgrades made available through LVFS.

Correctly here means zip file or unverified rom files, which notes were about above.

Is fwupd LVFS firmware images from Dasharo getting ready for production? If so, the above plan can be actioned upon and question is if zip files or rom files are to be dumped under /boot and in which dir and then I can work the plan.

Heads could act upon fwupd dropped firmware files under /boot.

Should fwupd Heads zip pack a detached signature inside of current zip produced from downstream to be hosted under LVFS so Heads can verify detached signature against public key fused in firmware? Otherwise zip file per flash-gui.sh currently only verifies SHA256 hash packed by Heads as of today, but doesn't validate it's authenticity. Authenticity to be manually verified against CI for hashes because reproducible builds, no authenticity verification provided as of today.

If integrity valodation is good enough per zip file, pressure should be done to users to make sure they refuse updates if they didn't ask for it from fwupd since authenticity would not be done equal by manual download today.

Fwupd is desirable and would be an amazing improvement for automated upgrades if strings of SMBIOS are consistent and limited to dasharo+heads from LVFS, which I abstract details here. If all of this is done and ready, then yes, I can go on an apply whatever is desired. Upstream heads would continue to need manual download of files, where Dasharo+heads could leverage fwupd and offer automated firmware upgrades as a service. That would be nice and differenciate paid subscription from rolling releases if done right.

Q:

  • rom or zip files to be provided by fwupd?
  • SMBIOS strings as desired to only upgrade dasharo+heads through LVFS, not heads upstream? Not other branding for same platforms, only dasharo-heads branding. I insisted on this being important before. I guess this is the place to revisit since now the importance makes sense? Do we want all boards to receive fwupd updates or only dasharo+heads under subscription? If so then SMBIOS strings really important as flagged before.
  • are detached signatures wanted/needed? If so, public key needs to be added under Heads so zip file content can be checked for rom detached signature prior of automated upgrade and fail close if not, preventing evil maid dropping files under /boot to automatically upgrade into.

Makes sense?

QubesOS implemented fwup in alpha mode since nobody uploaded heads to lvfs/fwupd usable as of today. Joint effort needed to do it right from above questions.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Qubesos support for fwupd was done as poc without anything under fwup to be tested against, while Heads is missing this PR to pick up correctly files dumped under /boot.

Correctly here means zip file or unverified rom files, which notes above were about.

Is fwupd from Dasharo getting ready for production (LVFS uploads getting ready?)? If so, the above plan can be actioned upon and question is if zip files or rom files are to be dumped under /boot and in which dir and then I can work a plan.

Heads could act upon fwupd dropped firmware files under /boot.

Should Heads pack a detached signature inside of current zip produced from downstream to be hosted under LVFS so Heads can verify detached signature against public key fused in firmware? Otherwise zip file per flash-gui.sh verifies SHA256 hash packed by Heads as of today, but doesn't validate it's authenticity.

If that is good enough, pressure should be done to users to make sure they refuse updates if they didn't ask for it from fwupd since authenticity would not be done by manual download.

Fwupd is desirable and would be an amazing improvement for automated upgrades if strings of SMBIOS are consistent and limited to dasharo+heads from LVFS, which I abstract details here. If all of this is done and ready, then yes, I can go on an apply whatever is desired

Q:

  • rom or zip files?
  • SMBIOS strings as desired to only upgrade dasharo+heads through LVFS, not heads upstream?
  • are detached signatures wanted/needed? If so, public key needs to be added under Heads so zip file content can be checked for rom detached signature prior of automated upgrade and fail close if not, preventing evil maid dropping files under /boot to automatically upgrade into.

Makes sense?

@Asiderr
Copy link

Asiderr commented Dec 2, 2024

Some of the job according to the flash-gui.sh was done here: #834
It was never integrated into source code due to blockers that are already resolved, so I believe that it might be good base for this solution.

rom or zip files?

Cabinet archives: https://lvfs.readthedocs.io/en/latest/upload.html

SMBIOS strings as desired to only upgrade dasharo+heads through LVFS, not heads upstream?

AFIK it was used to recognize version of the heads and it was used to recognize if any new updates of the heads are available:
https://github.com/fwupd/fwupd/blob/9b2655aca04c37ccc5e2f3482cdc5e6f1ec43639/contrib/qubes/src/qubes_fwupd_heads.py#L31

are detached signatures wanted/needed? If so, public key needs to be added under Heads so zip file content can be checked for rom detached signature prior of automated upgrade and fail close if not, preventing evil maid dropping files under /boot to automatically upgrade into.

Currently they are not used in original software. It might be a good idea to sign roms before they go into cabinets and check if they are properly signed during the upgrade.

Src related: https://github.com/fwupd/fwupd/blob/main/contrib/qubes/src/qubes_fwupd_heads.py#L113

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Cabinet archives: https://lvfs.readthedocs.io/en/latest/upload.html

@Asiderr cabinets are what is uploaded, but then fwupd from QubesOS extracts it. As of today I think it's rom, not zip since zip work for integrity validation landed later.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

SMBIOS strings as desired to only upgrade dasharo+heads through LVFS, not heads upstream?

AFIK it was used to recognize version of the heads and it was used to recognize if any new updates of the heads are available:
https://github.com/fwupd/fwupd/blob/9b2655aca04c37ccc5e2f3482cdc5e6f1ec43639/contrib/qubes/src/qubes_fwupd_heads.py#L31

@Asiderr yes. But if nothing SMBIOS differenciates those strings per rebranding between today's nitrokey / novacustom, dasharo+heads and heads rolling release, than fwup will propose updates for all sharing same SMBIOS strings, see branding discussions as per last nv41->n4x_adl change and SMBIOS strings discussions, some of which can be part of rebranding today, but needs confirmation for lvfs/fwupd before we stabilize them for that use case.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Currently they are not used in original software. It might be a good idea to sign roms before they go into cabinets and check if they are properly signed during the upgrade.\n\nSrc related: https://github.com/fwupd/fwupd/blob/main/contrib/qubes/src/qubes_fwupd_heads.py#L113

@Asiderr yes. I think we say the same thing. What I'm talking about is : ideally fwup would deploy the zip file produced by Heads today, which contains hashes.txt + rom, being enough for integrity validation but not authenticity. Since Heads build system produces those zip file, they could contain an additional detached signature (build system adaptation required for this so sign or repack externally) and be validated by the flash-gui.sh -> flash.sh refactoring I was talking about earlier, so that flash.sh that take a rom as argument could validate not only hash but detached signature if present, and flash.sh warning in case there is no detached signature, promoting both dasharo+heads subscription for extensively tested downstream version.

But again, smibios string here are primordial to be fixated once and for all prior of officializing the service so that only dasharo+heads get fwup notices of firmware upgrades and the chosen model here is worked toward design decision not impacting non dasharo+heads through lvfs/fwupd.

Fill me in on design decisions and adaptations desired, and what I should adapt iteratively to meet set goals.

What I'm interested in is what qubes fwupd will unpack, where and what Heads must adapt to to support fwupd/LVFS without it being a security issue for non dasharo+heads users which shouldn't be proposed fwupd updates, and if a rom dropped under boot, be clear it's an evil maid thing and nothing else.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Heads fwup marked experimental note
fwupd/fwupd@fedd851

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 2, 2024

Some of the job according to the flash-gui.sh was done here: #834
It was never integrated into source code due to blockers that are already resolved, so I believe that it might be good base for this solution.

I see versioning still problematic for upstream, but from rebranding I think the problem is solved?

@Asiderr let me know what I'm missing, will refractor flash-gui.sh so that validation logic under flash-gui.sh is under flash.sh following how this needs to be reprioritized.

flash-gui.sh currently deals with usb mounting, tgz/zip/rom checksum output if not zip file, etc, where flash.sh deals with the actual flashing(and rollback to prevent bricking in case anyrjing fails there under another PR). flash-gui.sh should not do tgz/zip/hash validation if no hashes.txt presented, it should be flash.sh doing that.

Then, if a fwupd dropped zip/tgz found under boot, flash.sh should do the right checks, prompt user for validation, check detached signature instead of hash validation (detached signature does both, is superior) and even proceed automatically if present after decompression, if detached signature found vs hashes.txt and if dasharo+heads (SMBIOS not matching) , big fat warning saying so. We do not want to prevent users switching to upstream but that switch of SMBIOS strings should be made easy to digest to end users, ie breaking warranty or whatever verbiage chosen here.

Food for thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants