Building coreboot from source (official script)

exploited · October 5, 2018, 1:47pm

Hello Kakaroto,
I was not able find in the entire thread answer to my issue, but there is mentioned similar one.
On my Librem 15v3 with Ubuntu 16.04 Lts the result of the build is the warning. I have put echo lines in the script in order to check the SHA1 hashes comparisons and there is difference.
There is the output:

…
The ME region can be reduced up to:
00001000:00111fff me
Setting the HAP bit in PCHSTRP0 to disable Intel ME…
Checking the FTPR RSA signature… VALID
Done! Good luck!

Finished building coreboot for Librem 15 v3

SHA calulated 4bd15cf62c91d224cf73d3eec6f9ca1eef707c2cfb5b005ce681133fcd4ec306
SHA referal 5a9b8e7f5e327e3b3fcb5513c091b6d476817fcf5a9c981c6d2727a220f4a30e
WARNING: Built coreboot image hash does not match the expect reproducible build hash

Can you suggest next steps?
Thanks

gnulligan · October 6, 2018, 4:05am

Hey @kakaroto!

I tried running your script but unfortunately it seems it didn’t exit gracefully.

The exact steps I took were:

sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff

chmod 744 ~/Downloads/build_coreboot.sh

sudo ./build_coreboot.sh

I then input “3” since I’m using a 13v2 and “1” since that was the default.

Below are the last few lines of output before the error:

(...) c++ -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DRAR_SMP -DUNRAR -c qopen.cpp c++ -o unrar -pthread rar.o strlist.o strfn.o pathfn.o smallfn.o global.o file.o filefn.o filcreat.o archive.o arcread.o unicode.o system.o isnt.o crypt.o crc.o rawread.o encname.o resource.o match.o timefn.o rdwrfn.o consio.o options.o errhnd.o rarvm.o secpassword.o rijndael.o getbits.o sha1.o sha256.o blake2s.o hash.o extinfo.o extract.o volume.o list.o find.o unpack.o headers.o threadpool.o rs16.o cmddata.o ui.o filestr.o recvol.o rs.o scantree.o qopen.o strip unrar Cloning into 'megadown'... remote: Enumerating objects: 540, done. remote: Total 540 (delta 0), reused 0 (delta 0), pack-reused 540 Receiving objects: 100% (540/540), 124.01 KiB | 1.39 MiB/s, done. Resolving deltas: 100% (261/261), done. Note: checking out '83c53ddad1c32bf6d35c61fcd12a2fa94271ff77'. 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: git checkout -b HEAD is now at 83c53dd Create LICENSE Downloading ME 11 Repository from https://mega.nz/#!DNdDVQ7I!hronBMVN8m82JciiT6UQwtwh-LVlHXIo-NzTB0324rk Please be patient while the download finishes… [pv] is required and it’s not installed REDACTED@Laptop:~/Downloads$

Was it successful? What’s [pv] supposed to be?

Edit:

I just read a bit more into the script, and I noticed it didn’t include the “pv” dependency in OP’s dependency disclaimer.

The dependencies command should be

sudo apt install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7 pv

and while python2.7 was included in PureOS by default, pv wasn’t, hence my error.

gnulligan · October 6, 2018, 4:22am

Hey @kakaroto

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:

https://0bin.net/paste/5GsbmrXc0t2zq-kw#lzWc9Ujikde7BGFZbK6jAKqkyTxFQf7K8a7udxuM265

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!

kakaroto · October 10, 2018, 12:50am

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.

exploited · October 10, 2018, 7:09am

Thanks for you reply, I will do the checks.

Wayne · November 4, 2018, 2:39pm

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.

2disbetter · November 4, 2018, 5:56pm

Just built the latest imagine for my L13 v3, and had no problems. Thanks!

bavay · November 14, 2018, 7:51am

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

florent · December 19, 2018, 6:17pm

Hi everybody

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).

Thank you very much

Flo

Smojo · December 21, 2018, 10:36pm

Yeah, I was a bit afraid as I have nearly no idea what the script is doing there but I successfully flashed

BIOS Information
        Vendor: coreboot
        Version: 4.8.1-Purism-3

to my Librem 15 v3.
Like some others reported pv was missing and had to be installed as well. I would recommend to add it to the wiki page.

Thanks @kakaroto and Purism

KingsLee · December 30, 2018, 11:08am

has anyone able to build coreboot and flash in Gentoo? mine failed at building gcc 6.3…

florent · January 9, 2019, 1:46pm

it’s resolved. My problem : i have multiple repository

peterpan · January 25, 2019, 4:11pm

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?

MrChromebox · January 26, 2019, 12:17am

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.

peterpan · January 26, 2019, 6:55am

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:

HEAD ist jetzt bei 83c53dd Create LICENSE

Downloading ME 11 Repository from https://mega.nz/#!2ElyFQDT!cC0gTlH8rB9EWD4MGX0mVElT94BauqFn-dBKuoEselc
Please be patient while the download finishes…

Reading link metadata…

The link seems valid, it was valid before I replaced the script as well

MrChromebox · January 26, 2019, 8:10am

wrong/outdated link, see: https://puri.sm/coreboot/, step 3 under ‘Building coreboot on your own machine’

(yes, I need to update some of the info on that page still)

edit: looks like the link in the first post redirects to the correct URL, so that wasn’t your issue

peterpan · January 27, 2019, 5:20pm

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?

MrChromebox · January 27, 2019, 7:04pm

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

peterpan · January 27, 2019, 7:57pm

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.

MrChromebox · January 27, 2019, 8:10pm

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.