Pureboot image changes after first boot

Hardware
1

Hi, everyone.

I have recently reflashed the firmware image on my Librem 14 with he newly updated Release-19, by using the official update script provided by Purism, while on a debian live system.

Immediately after flashing, I proceeded with re-reading the flashed firmware image with

flashrom -p internal:ich_spi_mode:hwseq -r current.rom

The sha1sum of the extracted current.rom indeed matched the one from the official image that was just flashed seconds before.

I then rebooted my machine and I was prompted with the expected alerts asking me to add gpg public keys to the keyring and to initialize a new HOTP code.

I skipped those steps because I didn’t want the firmware image to change, and I proceeded to boot again the Debian live USB.

I then extracted again the firmware image with flashrom (same command as above), but this time, to my surprise, the sha1sum of the extracted image dit not match the one of the image I flashed prior to rebooting.

I investigated further by comparing all the files in the two images (the official one and the one extracted from my system) with the help of cbfstool.
Each and every file was confirmed to be exactly identical between the two images, by comparing sha1sums.

Puzzled by the mysterious circumstances, I re-flashed the official image again, and once again I read back the contents of the flash with flashrom before rebooting: the flashed image’s checksum matched the official image’s.

I rebooted, again skipping the keyring creation and HOTP initialization.
After reboot, the firmware image content read by flashrom resulted again different from the one I had flashed prior to rebooting.

I repeated the above steps for 5/6 times, and every time I rebooted, the firmware image read via flashrom was different from the one I flashed.

I then created hexdumps of both the official image and mine and ediffed them to check what regions were different.
It seems like an entire flash region (not the cbfs one) changes from FF in the official rom to other hex values that I’m not able to understand or analyze further in the running firmware image.

So, here’s the question:
Is it expected behaviour for the flash contents to change after the first reboot?

I would expect that the flash contents remain the same forever after flashing; otherwise, how can one trust their own firmware to be exactly the one that was flashed?

Remarks:

  1. the flash image only changes after the first reboot after flashing: reading it after subsequent system boots always yields the same sha1sum, different from the one flashed originally, but consistent across reboots.
  2. I also tried injecting already-existing pubring.kbx and trustdb.gpg files prior to flashing, in the attempt to skip the keyring generation step altogether and it indeed skipped the keyring prompt at boot, but the image still resulted altered after the first reboot.
  3. every time I flash the image, the one that is read after rebooting is always different from the previous flash-and-reboot attempts, but the altered data are always in the same flash region (can’t tell what region it is).
  4. each and every time I reboot after flashing the firmware, the screen is blank for 2/3 seconds after powering on and before showing the pureboot splash screen, while the splash screen appears almost immediately in subsequent reboots.

Can someone help me solve this “mystery”?

Thanks.

@Kyle_Rankin and other puri.sm staff: I can provide you with the different flash images on demand.

2

Its likely metadata has changed, like the files’ last modified time.

3

Its likely metadata has changed, like the files’ last modified time.

What do you mean with metadata? Can you please explain a little bit?
The firmware image changed even when no files were added to the cbfs region, so this shouldn’t have to do with files’ metadata…

4

Sorry, I had skipped a portion of your post and misunderstood. I thought only the hash was changing.

5

Thanks for your reply.

Yes, the sha1sum is changing, but this has nothing to do with the metadata of the flash image file (e.g. pureboot-librem_14-Release-19.rom as a file).
It is the actual flash contents that are changing…

6

this is normal/expected behavior.

On the first boot following a flash, RAM training/optimization is performed (which is why the first boot takes ~30s) and subsequently saved in the MRC_CACHE FMAP region on the flash chip. If you were to extract this region from the downloaded image (it’s all 0xff) and write it to the image read after the first boot, then the images would once again match.

2 Likes