newbieAtGithub
commented
1 year ago hi @tlaurion
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, since we want to create additional wiki page, then i will make conclusion here, from https://github.com/osresearch/heads-wiki/issues/109 https://github.com/osresearch/heads-wiki/issues/110 https://github.com/osresearch/heads-wiki/issues/111 https://github.com/osresearch/heads-wiki/issues/112 https://github.com/osresearch/heads-wiki/issues/113 https://github.com/osresearch/heads-wiki/issues/114
All commits are signed, before being pushed into repository,
then being reviewed, before merging, & tested by regression testing,
This is how to distrust the infrastructures & ensure integrity,
across network, repository, Circle CI, local compile machine, & flashing tool.
2 ways, it verifies authenticity & integrity, prior compiling:
- commit signed, before being pushed into repository,
- git status will notify, if Heads' code base, related to specific commit, is modified. Name of generated ROM, will indicate, whether code base is clean or not.
If Heads' code base, related to specific commit, is modified, prior compiling, either Circle CI compiling, or Local compiling, then it will produce ROM, & "-dirty" will be appended to the ROM name, to notify user that the ROM build is not clean, otherwise, if ROM name contains no "-dirty", then we can assume it is clean.
Commit ID will be appended to the ROM name, as an information, that the ROM was built, by using what commit.
hashes,txt containing hashes of built files & ROM, will be generated after built, & can be used to verify integrity, for 3 conditions:
- after local compiling
- after Circle CI compiling & download
- after flashing & backup (external / internal flashing & external / internal backup)
hashes.txt generated, after built, will only contain hashes for built files & ROM, it will not contain any hashes for any files before built.
Currently, Heads has reproducibility issues, which mean, using different machine, to build / compile Heads, i.e. using Circle CI or Debian laptop or docker, will produce ROM with different hash / checksum.
hashes.txt will show individual hashes, of everything packed in the firmware, and also the firmware image itself. If final hash of final ROM image is same, it means all parts inside are good.
Compressed under initrd.cpio.xz:
- heads.cpio contains all the scripts and configs under initrd dir of github
- tools.cpio contains all the compiled binaries and libraries
- modules.cpio contains all kernel modules that were packed for a board Coreboot does its stitching and includes the kernel and initrd as its payload.
hashes.txt under ./blobs/ section, are different from hashes.txt, generated during compiling:
- hashes.txt inside ./blobs/ contains hashes for blobs (me, gbe, ifd) , i.e. xx20, hashes.txt
- hashes.txt generated during compiling, contains hashes of files & ROM, that are produced by compiling.
- hashes.txt generated during compiling, will contain no hashes for blobs (ME, GBE, IFD).
Blobs (ME, GBE, IFD) will have different hashes, they are unique for each laptop:
- me.bin has different version, therefore has different hash
- gbe.bin has different MAC address, therefore has different hash
- ifd.bin contains information from motherboard, there has different hash
By using blobs (ME, GBE, IFD) from Heads repository, then we will have same blobs & its hashes, & also same MAC address, as other Heads' user. But using your own blobs, will have unique MAC address & motherboard info, etc.
Flashed Heads ROM, will contain MRC cache, GPG public key ring, & config.user override. Therefore, while backup-ed, will have different hash checksum, so need to extract / unpack 1st, then validate extracted component with hashes.txt, of same commit.
Re-flashing / Updating Heads externally, provide more integrity, than internally re-flashing / updating, but for most cases, is not necessary. Internal flashing rely on internal flashrom tool, in case of distrusting the internal flashrom tool, then can do external re-flashing. Re-flashing externally will invalidate measurements, since the ROM won't contain the same GPG key ring. The risk of flashrom being compromised is low, but possible.
Internal flashing, rely on internal flashrom tool. sha256sum -c is a subprogram of busybox, to check digest integrity.
After re-flashing, check integrity internally, by using sha256sum of internal busybox, and take backup internally / externally, & unpack / extract for external re-check.
tlaurion
marmarek
krystian-hebel
This is raw notes. This will get edited multiple times prior of having a base to create a wiki page.
The quick way, no-brainer, is to reflash the same downloaded/compiled firmware and keeping settings, as already documented at: https://osresearch.net/Updating#reflashing-the-same-firmware
Unless flashrom itself was compromised (meaning that the payload is tampered), reflashing the same firmware image using the menu options to flash new firmware while keeping settings will reflash IFD+ME+GBE+coreboot+payload+current CBFS files. Since coreboot measures its bootblock + ramstage+romstage+payload, and then Heads measures added CBFS content, TOTP/HOTP measurements should be the same, and TOTP/HOTP unsealing of secrets should match.
But that doesn't answer the introspection need of some users to actually validate that the firmware components are actually in the expected state. And those notes, even better, if translated into code, should answer those needs.
Taking an internal backup of the firmware to be inspected externally
From Heads Recovery console, one can easily obtain actual BOARD_NAME and FW_VER that includes the bits we want to differenciate properly the actual board and flashed Heads commit ID in case we want to go back.
From Heads recovery shell, with a USB thumb drive ready to receive backup, we mount usb drive in read+write and we take a backup with proper naming scheme:
Extracting content from that firmware image for validation
Unfortunately, coreboot-utils are precompiled for a limited number of distributions today. I'll take for granted here that debian12 is installed under QubesOS (see unman's repo https://qubes.3isec.org/Templates_4.1/) Then a quick
sudo apt install coreboot-utils binwalkwill make the tools available with/without sudo.Each Heads board's build comes with a hashes.txt file. It is either dowloadable from CircleCI artifacts, or can be seen, and copy pasted from a build's output given on screen. Following download instructions will lead you to the hashes step of any CircleCI build: https://osresearch.net/Downloading
Now. After having mounted our USB thumb drive under a debian-12 based qube with tools installed, from command line, having passed the USB thumb drive to our newly booted qube:
And then we work on our copied to memory image.
We can extract partitions not managed from coreboot actual versions measurements:
Here one could compare ME against what is downloaded and extracted from Heads scripts, GBE and IFD configs against what is stored under Heads tree.
But most questions are related to the firmware integrity itself, Heads itself:
Here again, a lot of stuff there.
Get build hashes for current rom
x230-hotp-maximized-Heads-v0.2.0-1296-g139ecb8_backup.rom is commit 139ecb8 We go over https://github.com/osresearch/heads/commit/139ecb8 We click grewn mark, follow the rabbit to the build for x230-hot-maximized at https://app.circleci.com/jobs/github/osresearch/heads/5448, click the "Output hashes" if this is an old build without artifacts, and copy the output of the hashes there to a local hashes.txt file we make sure to have available for our situation. We can directly save the output from CircleCI's Download Icon, which in our case leads to https://circleci.com/api/v1.1/project/github/osresearch/heads/5448/output/104/0?file=true&allocation-id=63751e76e6fb893f12bf3473-0-build%2F97AF006
From now on I consider we have that file saved into hashes.txt to be used locally.
Extract content from coreboot's payload
We now have coreboot's payload.
We extract the content with binwalk
So we have a matching initrd.cpio.xz into 2E531F.xz We could dig more into that, and will (after all, everything hashes.txt is detailing why we have a match for the payload).
hashes.txt can be used under recovery shell to verify hashes of the initrd binaries
The paths undr hashes.txt are relative. If we have hashes.txt under USB thumb drive, from Heads recovery shell: cd / mount-usb sha256sum -c /media/hashes.txt
Will give OK reports for all files that were found, including libraries and binaries and scripts user by heads, as seen under
Check bzImage
Unfortunately, this requires CircleCI bzImage since mathing can only be made against decompressed binary.
After our binwalk --extract command:
Download bzImage from CircleCI artifact