Thanks to @stefann, I’ve fixed the issue that was causing the hash to not match [1].
You should re-download the script now and re-run it, and it should work this time. If you still have issues, let me know!
[1] the problem was SeaBIOS itself, the coreboot config stated to build the latest git master of SeaBIOS but of course, there were new commits in git in the past few days, which made the hash different. I’ve now changed the config to tell it to build a specific version of SeaBIOS and that should fix it.
EDIT: I’ve just added a new option to let you neutralize the ME. I’d appreciate it if some of you could test it and see if there are any side effects that you can notice. The biggest one I want to test for is whether you have any reboot or power off issues when you run the neutralized ME.
If you have issues, and want to restore the ME to a normal state, then flash the coreboot-l13v2.rom or coreboot-l15v3.rom image.
Reporting a typo: mircocode instead of microcode. Does the script detect if the installed version of coreboot is the same as the target version and exit if so?
Thanks! Fixed the typo.
And no, the script doesn’t detect your installed version because it’s not an updater script, it’s a build script. So it’s meant for you to build coreboot from source, regardless of the version you have (which might be useful in case you think someone installed a modified&malicious version of coreboot, but which appears as the same version as the one you have). The updater script, once itself has been updated to support skylake machines will check for new versions instead (and I think I’ll also make it check hash of current firmware in case it’s the latest one).
I get the same warning message when I use the up to date script and run the neutralized ME. I’ll test this image some more and tell you if there are any side effects.
Humm… I remember seeing that as well, but can’t remember if it disappeared on its own, if I did something to fix it or if I just stopped noticing it. Either way, I think it’s not an issue because it’s just complaining about the display port not having enough lanes (being disabled?), and the crash is clearly a bug in the kernel driver itself… humm… possibly it stopped happening when the kernel/OS got upgraded?
oh, just tested on the L13 and L15, and it’s still there, yeah… so I just stopped noticing it. I’ve created a task for it so it doesn’t get forgotten again. Thanks for reporting it.
Not a dumb question at all. Yes, you can run it from a live USB and it should work. If it doesn’t, then alternatively, you can run it on a separate machine, but you will need two things :
Dump the flash from the librem manually
Flash the new coreboot image manually
If you run the script on the live USB, it will compile flashrom then dump your flash. You could then interrupt the process and copy the coreboot-orig.rom file over to your second machine, then run the script, when it asks about where to get the blobs, choose option 2 (grab them from the pre-dumped file). Then once the build is finished, copy the coreboot-l1[35]v[23].rom file it generated and flash it on the librem using this command : coreboot/flashrom/flashrom -p internal:laptop=force_I_want_a_brick -w coreboot-l13v2.rom
(this is assuming it was built for l13v2, and you run it from the same dir you ran the script earlier, since flashrom will be built under coreboot/flashrom sub-directory)
I just wanted to tell you that after testing coreboot with the neutralized ME for one week now (8–10 hours a day) I didn’t have any issues at all. Everything works as expected.
The alias gets installed with the “make gitconfig” command. Your problem is this : make: command not found
I am however surprised that the error in the make didn’t cause the script to abort. I’ll check tomorrow if I forgot to set the -e option in the script
@kakaroto I did what (I guess) you wrote at https://puri.sm/coreboot/ in section Checking whether or not the Intel ME is neutralized in your image but the first seven lines don’t match… Here’s my output:
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code : <NULL>
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code : <NULL>
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
I used your script to install coreboot with neutralized ME (see above) and I thought it worked… Since I just did what I read and don’t understand the output at all – could you tell me what it means?
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code :
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
REDACTED@mojo:~/coreboot/util/cbmem$ cat /proc/cpuinfo | grep microcode | wc
4 12 68
Yeah… that information is for the Librem 13 v1. It’s much harder to verify if the ME is disabled on the skylake system and that was the last thing I was working on. The way I do it is to just dump the flash and used a hex editor to check if the ME in it is neutralized or not (zeroed out modules and removed partitions), but obviously that’s not practical for anyone.
Unfortunately, I think coreboot is booting so fast on the skylake systems that it finishes booting and probing the ME before the ME encounters its first “module missing” error and crashes.
There’s the intelmetool in coreboot which could be used to talk to the ME and see if it responds to requests or not, but it hasn’t been ported to skylake yet I think. I suppose that for now, you just need to trust that if you flashed it and enabled me neutralization, that it is indeed neutralized.
Tried the current script today in the vain hope this might fix issues with the new Qubes4.0rc2 not recognizing IOMMU/VT-D as enabled. Unexpectedly though it produced some fatals & warnings and finally broke when it found the hash of the downloaded ME repo to be wrong.
Script was run from a fresh PureOS with additional necessary packages installed on a Librem13v2. I logged the whole output: http://dumptext.com/10v1R18M
Hereby pinging @kakaroto about this. Any ideas what might have gone wrong?
@avog: well that’s interesting, thanks for the log. I tested and I got the same issue. It looks like the mediafire link had its file updated. The ME repository pack went from r48 to r49. I always thought the medialink files were static, so I thought the r49 (when they’d upload it) would be a new link, but it looks like that’s not how it works. Anyways, I’ve updated the script to handle the new filename and hash, so just the script and rerun it, it should work now.
Note however, that the IOMMU stuff still isn’t enabled. That will still require some time to get implemented.
Thanks @kakaroto, it’s working again. And like many others I’m very much looking forward to “the IOMMU stuff” being enabled. My Librem has been sitting here waiting to run a fully functional Qubes installation ever since I got it.
