You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
This is a separate question… But how vulnerable is your script to MitM attacks and malicious firmware?
Regarding MitM attacks:
On a cursory glance, your script does check SHA256sums of the downloaded files, which is great, but there is no checksum available for the script itself, meaning there is the possibility of the script (and therefore the included checksums) being modified by an attacker (the same thing happened to the linux mint website not too long ago… The ISOs and checksums were modified by attackers at the same time)
If you included checksums for the script and had them hosted on a different server, that would give an additional layer of security and confidence to whoever used your script.
I made a 0bin of the checksums, with no expiration here:
If they’re correct, I’m sure others would appreciate having them.
Regarding malicious firmware:
I also noticed your script says it extracts the binary blobs from the machine being run on. Are the hashes of the blobs on the local machine checked as well? Or are they assumed to be good because they’re not downloaded?
Thank you for your patience with all my questions!
Did you check the git version? I believe it happens only when the git version you use is too old (which gives a different output on ‘git describe’)… look in this thread for more info about that.
The script is taken from the git repo and the last git commit is signed by me with my GPG fingerprint available in the purism’s About/Team page.
Yes, every single one. The only exception is the ME firmware on the Broadwell (l13v1 and l15v2) machines because the hash changes from one machine to the next, although I think that if we clean out the ME after dumping it, we can get a unique hash for all machines.
I finally got the courage to update my firmware, and it looks like I was successful.
I suggest updating the instructions on the Purism coreboot page, because the output from cbmem enumerated there is different from what is expected now for Intel ME. This is judging from others’ posts, e.g. @tez, and my experience. I too see ‘FW Partition Table : BAD’.
Updating firmware is scary enough without seeing different expected results.
UPDATE (11/6): I created a new tracking task to update the output on this page.
Hello! I’m still coming with my L15 v2 questions… I’ve edited your script to accept the L15 v2 (with the proper checks for it), but now it returns an error when checking the files it downloads from the ChromeOS repository:
Intel Firmware Descriptor file hash does not match the expected one
Is there anything I can do there? Is it that the hash should be different (so I should just regenerate one) or is it that something is going wrong?
Thanks,
Mathias
Verifying hash of file : chromeos_8743.85.0_tidus_recovery_stable-channel_mp-v2.bin.zip
File hash is valid: d17650df79235dca0b13c86748e63c227e03c401
Decompressing the image…
Verifying hash of file : chromeos_8743.85.0_tidus_recovery_stable-channel_mp-v2.bin
File hash is valid: 72240974b72d5328608a48c0badc97cf8653a5f4
Extracting ROOT-A partition
Verifying hash of file : chromeos_tidus_root_a.ext2
File hash is valid: 038dd8cfae69565457e45c1e1a7515a411a32fb3
Extracting chromeos-firmwareupdate
Verifying hash of file : chromeos-firmwareupdate
File hash is valid: fff693b74088f79d292c17c9ef5efacdba8915f8
Extracting coreboot image
Verifying hash of file : chromeos_tidus_bios.bin
File hash is valid: 3775dd99a1e4e56932585ce311e937db12605e2f
Extracting Memory Reference Code: mrc.bin
Verifying hash of file : mrc.bin
File hash is valid: eb2536a4e94c6d1cc6fe5dbd8952ae9b5acc535b
Extracting Intel Broadwell Reference Code: refcode.elf
Verifying hash of file : refcode.elf
File hash is valid: e3f985d23199a4bd8ec317beae3dd90ce5dfa3cc
Extracting VGA BIOS image: vgabios.bin
Verifying hash of file : vgabios.bin
File hash is valid: 17db61b82e833a8df83c5dc4a0a68e35210a6334
The VGA BIOS binary has been extracted from your current BIOS.
Extracting Intel Firmware Descriptor and Intel Management Engine images
Verifying hash of file : flashregion_0_flashdescriptor.bin
File hash is invalid. Found c762f1f7e6c9c8663778d07c6198ec245e77e6f4, expected 359101061f789e1cfc13742d5980ac441787e96c
Intel Firmware Descriptor file hash does not match the expected one
I try to execute bash to upgrade coreboot from source but it’s hard to install libpci-dev
sudo apt install libpci-dev
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites
libpci-dev : Dépend: libudev-dev (>= 196) mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».
My repository is pureos green and I have a librem13 V2 (coreboot version 4.7-Purism-4).
Ok, tried to build coreboot today and it stops right after the step to download the ME 11 repository pack. Network connection is working and the file on megaupload is still available. Any idea?
did you download the build-coreboot.sh script fresh from source.puri.sm/coreboot per step 3 in the instructions? If not, that’s your issue. The ME repository URL has been updated (among other changes) so you want to me sure you’re always using the latest build script, in order to get the latest coreboot version/latest components. I just re-tested it here any everything looks good with the ME repo download.
thanks for your reply.
Well, I took the link from the first post and executed it a second time (the first time was from the coreboot blog article released from purism a while ago), at the end it says that I’m in a detached HEAD and afterwards it stops after this:
I don’t want to sound superstupid, but I did all these steps exactly as they’re written on that post again, but it still stops at the message above.
I tried to do that on a Librem 13v3 on PureOS, so maybe you’re doing something different to have a positive result?
I’m building/testing under PureOS on all our shipped devices. Since I just pushed the 4.8.1-Purism-4 update, I build/tested on each. The ME repository link above is valid and downloads correctly for me. Are you able to download it using the mega URL from a browser? If not, that would imply something on your end is blocking the download (could be machine, router, ISP, etc). If so, then simply rename it to ‘me_11_repository.rar’ and put in coreboot-files/coreboot/ where you are running the script
I thought that as well, so I tried to download the link rar-archive manually and this works without any problems. I suppose, the script doesn’t even try to download the archive, it immediately shows “Reading link metadata…” after the echoing “Please be patient s.o…”
So I uncommented the call to megadown and placed the rar-archive directly in the correct directory and voila: it’s working
I even tried to replace the path to megadown to the absolute path and tried to use megadown standalone. Megadown itself works, but not the call from the buildscript.
I don’t have a good explanation for your issue then. The script absolutely does down the archive, it even downloads a component in order to be able to directly download from mega. But I’m glad downloading manually has mitigated the issue for the time being.
so finally figured this out, the megadown script was failing if the output file already existed, instead of overwriting, when the hash didn’t match expected. I’ve pushed a fix to address this, so please let me know if you continue to experience the issue
I’ve edited your script to accept the L15 v2 (with the proper checks for it), but now it returns an error when checking the files it downloads from the ChromeOS repository: