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

Reflashing / Updating Heads - Internal vs External #110

Closed
newbieAtGithub opened this issue Dec 5, 2022 · 4 comments
Closed

Reflashing / Updating Heads - Internal vs External #110

newbieAtGithub opened this issue Dec 5, 2022 · 4 comments

Comments

@newbieAtGithub
Copy link

hi @tlaurion

which one provide better integrity, internal or external Heads re-flashing ?

thanks & regards,

@newbieAtGithub newbieAtGithub changed the title Reflashing Heads - Internal vs External Reflashing / Updating Heads - Internal vs External Dec 5, 2022
@tlaurion
Copy link
Collaborator

tlaurion commented Dec 6, 2022

which one provide better integrity, internal or external Heads re-flashing ?

External is better, but unneeded in most cases?

Can you detail your concern? I think I answered this partly under references given under other #111 #112 #113 #114 issues you opened targeting different angles of the same question, which all goes to: if you build yourself, and that you can verify that got checkout is clean, that ROM is not "dirty" and that you flash and reflash the same firmware externally and internally with same TOTP/HOTP valid attestation, and TPM disk encryption key passphrase releases the encryption key and boots the final OS correctly, then the firmware being reflashed keeping those valid should reassure you.

@newbieAtGithub
Copy link
Author

hi @tlaurion

Can you detail your concern?

my concern is, if we are unsure, about the integrity of the flashed image,
let's say the flashed image has been compromised,
is it still okay, to update Heads, by re-flashing update internally ?

External is better, but unneeded in most cases

in what case we need external re-flash ?

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 9, 2022

https://osresearch.net/Updating#reflashing-the-same-firmware

Once builds will be reproducible again, any ROM build locally or on CircleCI will have the same final hash, and hashes.txt will be the same for a got commit.

Until then, reflashing thr same firmware internally should be enough to reassure most, where backup of same ROM and unpacking it to verify should also be enough.

One could verify the hash for flashrom, trusting internally that the checksum is reported correctly, meaning that busybox is not compromised. One should backup the ROM and inspect it externally against hashes.txt to make sure everything is good.

When internally flashing, flashrom is used. When checking for digest integrity, sha256sum -c is a subprogram of busybox.

Once again, the only real good option to backup and verify an untrusted ROM, if radical, would be to take a backup externally, unpack the ROM and verify its hashes to be as expected.

Reflashing externally will invalidate measurements, since the ROM won't contain the same gpg keyring. This is why reflashing internally should be the first step, after having took a backup of the ROM to be inspected.

The risks flashrom being compromised are again really low while possible.

I would advise into asking specific questions in the issue I created as raw notes for integrity validation, which hopefully will result into an additional wiki page to answer all those questions.

@newbieAtGithub
Copy link
Author

hi @tlaurion

okay, in short, you suggested that external re-flash is better, but not necessary, because:

  • internal flashing requires internal flashrom only
  • the risk of internal flashrom being compromised is really low, although possible
  • we can use busybox's sha256sum -c to verify internal flashrom
  • also can internal backup the flashed rom, unpack & inspect it externally against hashes.txt
  • Reflashing externally will invalidate measurements, since the ROM will contain different gpg keyring

I would advise into asking specific questions in the issue I created as raw notes for integrity validation, which hopefully will result into an additional wiki page to answer all those questions.

okay

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

No branches or pull requests

2 participants