Hi. I ran the script on a Librem 13 v2 and all went well. I have since reset the laptop by reinstalling Pure OS. Do I have to run the coreboot script again or do those changes survive reinstallation of the OS? Thanks.
Alright so lets assume for a second that running the core boot build script in my situation is not possible. Is there currently a mechanism I can employ to obtain a pre-built image for my Librem 15 v3 which I can just flash on my own? I see there is a coreboot updater purism git repo but it indicates that it is only meant for the Librem 13 v1 so…
My primary goal is to update my firmware/coreboot so that Intel ME is toast. For the time being I’m fine with either using an image to get there or being able to build it myself.
Any suggestions or pointers would be most appreciated, thanks!
I’m running into this issue on my Librem 13v2 as well. I’m also running Arch, so it might be worth revisiting whether that is the cause.
Built purism/librem13v2 (Librem 13 v2)
File build/coreboot.rom is 16777216 bytes
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00200000 - 00ffffff
Flash Region 2 (Intel ME): 00001000 - 001fffff
Flash Region 3 (GbE): 07fff000 - 00000fff (unused)
Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused)
Flash Region 5 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 6 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 7 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 8 (EC): 07fff000 - 00000fff (unused)
Cloning into 'me_cleaner'...
remote: Counting objects: 217, done.
remote: Compressing objects: 100% (128/128), done.
remote: Total 217 (delta 126), reused 157 (delta 89)
Receiving objects: 100% (217/217), 68.56 KiB | 403.00 KiB/s, done.
Resolving deltas: 100% (126/126), done.
Note: checking out 'origin/extra_partitions'.
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 <new-branch-name>
HEAD is now at 9facf98... Change debug line to avoid confusion with new --extra-partitions argument
Full image detected
The ME/TXE region goes from 0x1000 to 0x200000
Found FPT header at 0x1010
Found 11 partition(s)
Found FTPR header: FTPR partition spans from 0x2000 to 0xa9000
Found FTPR manifest at 0x2478
ME/TXE firmware version 11.0.18.1002
Removing unused partitions...
b'FTPR' (0x1000 - 0xa8000 (0xa7000 total bytes)): removed
b'FTUP' (0x110000 - 0x1bc000 (0xac000 total bytes)): removed
b'DLMP' (0x0 - 0x0 (0x0 total bytes)): removed
b'PSVN' (0xe00 - 0x1000 (0x200 total bytes)): removed
b'IVBP' (0x10c000 - 0x110000 (0x4000 total bytes)): removed
b'MFS\x00' (0xa8000 - 0x10c000 (0x64000 total bytes)): removed
b'NFTP' (0x110000 - 0x1bc000 (0xac000 total bytes)): removed
b'ROMB' (0x0 - 0x0 (0x0 total bytes)): removed
b'FLOG' (0x1bc000 - 0x1bd000 (0x1000 total bytes)): removed
b'UTOK' (0x1bd000 - 0x1bf000 (0x2000 total bytes)): removed
b'ISHC' (0x0 - 0x0 (0x0 total bytes)): removed
Removing unused partition entries in FPT...
Traceback (most recent call last):
File "./me_cleaner/me_cleaner.py", line 638, in <module>
mef.write_to(me_start + 0x14, pack("<I", len(new_partitions) / 0x20))
struct.error: required argument is not an integer
EDIT: This is because some of me_cleaner.py is incompatible with Python 3, which Arch uses by default – see this thread for details. Until this is fixed, a temporary workaround is to hardcode me_cleaner.py to use Python 2 instead.
Worked perfectly for me. I’m now Intel ME free! Thanks aarmea! Hopefully the purism maintainer can get this python 2/3 glitch worked out in short order.
@jaylittle@aarmea great to know you got it working. I saw the other thread about it and already answered there.
I’ll just answer your mention of the updater script. That script needs to be updated to work with the skylake machines, unfortunately, I don’t have time to handle it right now, which is why it’s not done yet. Either way, we can’t just distribute the image because of licensing issues, so the script would still need to create the resulting coreboot image then run me_cleaner on it, so in your specific case, it wouldn’t have helped since the error was with me_cleaner.
I’m a bit of a newbie, however I managed to run the script on a Librem 13v2. It completed without any errors and the hash matched, so it offered me to flash, which I did.
My question is: is this the output I should expect after flashing / rebooting? (Flashed November 7th):
~/coreboot/util/cbmem$ sudo ./cbmem -c | grep ^ME
ME: FW Partition Table : BAD
ME: Bringup Loader Failure : YES
ME: Firmware Init Complete : YES
ME: Manufacturing Mode : YES
ME: Boot Options Present : YES
ME: Update In Progress : YES
ME: D3 Support : YES
ME: D0i3 Support : YES
ME: Low Power State Enabled : YES
ME: Power Gated : YES
ME: CPU Replaced : YES
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (15)
ME: Current Operation State : M0 without UMA but with error
ME: Current Operation Mode : M0 without UMA
ME: Error Code : Preboot
ME: Progress Phase :
ME: Power Management Event : CM0PG->CM0
ME: Progress Phase State : Unknown phase: 0x0f state: 0xff
ME: Power Down Mitigation : YES
ME: PD Mitigation State : Issue Detected but not Recovered
ME: Encryption Key Override : Workaround Applied
ME: Encryption Key Check : FAIL
ME: PCH Configuration Info : Changed
ME: Firmware SKU : Unknown (0x7)
ME: FPF status : fused
@tez: Yep, that’s perfect, it says YES everywhere and partition is BAD because the status is 0xFFFFFFFF because the ME is disabled and even coreboot can’t get the status.
EDIT: I saw you elsewhere wondering if it’s right because previous comments and @mladen posted a different expected output. Well, that’s because those posts are older, and when they were posted, the ME was only neutralized. The ‘ME disabled’ is newer and gives a different output, as you can see. Yours is the correct/expected output for a disabled ME.
It should be “cbmem” not “./cbmem”, and if you’re on PureOS, make sure you first apt-get install coreboot-utils. Otherwise, you need to grab cbmem from the coreboot/utils/cbmem source directory and compile it.
I have no idea what you mean about BusyBox…
I did a quick review and you don’t do any error handling and your interpreter is wrong. It should be /usr/bin/env bash as /bin/bash is not guaranteed to exist.
Many of the variable references are not double quoted when they should be.
Don’t feel discouraged, however. Apparently people are happy with it, so doing something is better than doing nothing. It’s just that it could be written in a more portable way.
You could just check for the dependencies before the script runs and output appropriate error messages. That way you won’t have users complaining to you about your script not working.
Writing the error checking code is just as much work as writing the comments.
Would I be able to build this with a different payload?
Say for example I wanted the GRUB2 payload, so I went into config.librem15v3 and set “CONFIG_PAYLOAD_GRUB2=y”, then commented out anything relating to SeaBIOS. Would it build?
I don’t yet have the Librem 15 to test it out. Being able to get Coreboot with a disabled Intel ME and GRUB at the BIOS level, allowing for full-disk encryption including the /boot partition (like this), is a big factor in my decision to buy it in the next week or so.
I’m not a bash developer, but I ran it through shellcheck.net and fixed all the warnings, errors and suggestions it gave me. If you have other suggestions to give, then feel free to send a pull request.
No, the variable references are double quoted wherever they should be, shellcheck makes sure of that.
I’m not discouraged, why would I be ?
I haven’t really seen people complaining about the script not working. I could check for the dependencies but I didn’t because the script was meant to be released as a .deb. The comment was meant for the deb developer who is going to build the package with the script.
Since you’re the only one that seems to be bothered by it, I’ll repeat my advice from above, feel free to send a pull request with your fixes.
Yes, you could, but it’s not as simple as modifying the config.librem15v3 because of the following reasons :
The script would checkout a clean clone of that git repo and copy the config file from there, so your changes would be ignored anyway
Modifying the config file manually is not supported by coreboot, when you type ‘make’, it will regenerate the config file somehow, and may or may not override your settings
Enabling one option could create new config options that need to be set which aren’t even listed in the config file
The script verifies that the build has the expected hash, if you change a single thing in the config, the hash won’t match and the script will think that some error happened which caused a corrupted build and it won’t ask you to flash it and will show you an error.
What you could do however is that you would first build it normally, then after it’s done, go into the coreboot directory and do ‘make menuconfig’. In the menu, go to payload and change the payload, then save config and exit the menuconfig. Then when you do ‘make’, it will compile coreboot with your new options (grub). After that, you need to create a serial_number.txt file and put your machine’s serial number in it and use cbfstool to insert the serial_number.txt file into the resulting coreboot.rom image (otherwise, when you boot, dmidecode will report ‘unknown serial number’)… the method and arguments to do that are in the script file, then you’d need to run the me_cleaner script on the resulting build/coreboot.rom file (required arguments are in the build script). then you need to flash it manually (arguments to flashrom are in the build script). Once it’s flashed, and that’s the big issue, you would need to cross your fingers, reboot and HOPE that it will boot into your machine. Because if the grub config file (which also needs to be provided and embeded in the coreboot.rom file) is somehow wrong and grub doesn’t detect your drive (because you made a typo in the partition name, or something… anything…), then you can’t boot your machine. If you can’t boot your machine, you won’t be able to fix the grub config file and re-flash it. so you would need to buy a hardware flasher, open the laptop and flash a known-working coreboot image back into your flash so you could boot it again.
so in short, yes, you can do it, but it’s not as simple as changing the config file. I don’t even know if you could have grub boot from your usb, or maybe you can enter a ‘grub shell’ and manually type the commands to make it boot from a usb stick so you could boot into a live USB and restore your system… but that also assumes that the graphics are initialized, which is something that SeaBIOS does, and I don’t think that grub does that, so you might also need to edit the coreboot configuration to tell it to run the VGA Option ROM and to initialize the GPU, otherwise grub might appear but the screen is off and you can’t see anything…
All these complications are why the script checks the hash and makes sure the image it builds and flashes is a known working image. If you have, or are willing to buy an external flasher and play with it until it works for you, then feel free to do so. I am however too busy with other tasks to try and test/confirm that every payload would work (I know that MrChromeBox has unofficial builds that use TianoCore as the payload, I’m not sure if he released those anywhere though).
To quote Lloyd Christmas, “So you’re telling me there’s a chance.”
Really though, I’ll probably give it a shot. The alternative if I wanted this setup is to either buy a Librebooted decade-old ThinkPad or buy similarly spec’d hardware to the Librem and definitely need a Rasperry Pi and a Pomona clip. At least this way there’s a CHANCE I won’t need to do any hardware flashing, provided I don’t screw anything up.