Go man go! Let us know if u brick or win
2 Likes
Two questions about coreboot, Intel ME disablement and the Librem 15v2.
- I recall having the impression that coreboot was not going to work but the Intel ME could possibly be disabled in the 15v2. If this is correct, can you point me towards info that would let me start learning how to do this?
- I keep wondering when the coreboot development for 15v2 will begin. Itās felt like it might be just around the corner for some months now, which tells me I had the wrong expectations. Is there much more to go before that can usefully start? Or is there a particular milestone in porting coreboot to the other systems I should look for to know user testing on the 15v2 can usefully start?
Sorry about the 2nd question, just feeling a bit lost on where weāre at with it and that doesnāt pair well with having a lot of interest in the end goal.
Thanks for the script.
Could you please provide some way of checking the authenticity of it (I know I could read it to see whether it is malicious, but then I still need to trust the hashes contained in it).
I would like to upgrade coreboot to get the disabled ME, but I am reluctant to run an untrusted script downloaded from the internet with root privileges.
yeah, there is a chance. Iād suggest you read carefully all of my previous technical blog post on coreboot just to get familiar with the whole thing. You can find my posts on the right sidebar here : https://puri.sm/coreboot/timeline/
Well, both coreboot and ME disablement would work on the l15v2, but the ME disablement would be much easier to achieve than the coreboot port, since all youād need to do is run me_cleaner on it. So āstepsā would be : flashrom to dump your ME, run me_cleaner on the rom (use -s to tell it to set the disable bit), then flashrom to flash it back. Then reboot and cross your fingers and start praying that it doesnāt brick it.
Yeah, I donāt know āwhenā. And no, you didnāt have the wrong expectations, because yes, it also felt like itās right around the corner for me too. I did do one attempt at it. Did the port, thought it would work, flashed it, it bricked the l15v2 that I had. I restored it with the hardware flasher, and was trying to understand why it failed to boot from the log files I had, but didnāt finish that and got sidetracked by something else. For now, I think that the priority is on other tasks and I havenāt had time to go back to that work. Itās really all about man power and how much stuff I can achieve every week. Soā¦ āwhenā will it startā¦ I have no idea, for now my priority is on the FSP reverse engineering, so maybe if enough l15v2 users start bugging us about the coreboot port, the priorities will change.
Itās not that we donāt want to do it, itās still planned, but since l15v2 isnāt being sold anymore, I think the priority will most often go to the current products in favor of retrofitting older products.
The script builds coreboot from source. You can either trust the script and trust the coreboot source code, or you can read the source to know what it does. The hashes contained in it are just the hashes for the binary blobs themselves, there is nothing that can be checked on those (we donāt know if they are malicious or not) and those files are taken directly from your own machine. The only other hash is the resulting binary of the coreboot rom file after it gets built from source. You donāt need to trust that hash, you only need to trust the source code of coreboot, since the hash verifies the result of the compilation from source.
As for the root privileges, you donāt need to run it as root, but it will call āsudoā for a few commands. You can look up āsudoā in the script, there are 3 instances of it, first is the call to āflashromā to dump the rom (to extract the binary blobs from it), then a call to āsudo dmidecodeā which is used to get the serial number from your current machine, then a final call to āflashromā to write the built coreboot rom into the flash. The rest is executed without root priviledges, and I usually run it as a normal user.
1 Like
Could you incorporate more recent updates from https://review.coreboot.org/#/q/purism ?
I fear bricking the device when compiling from mainline but need the librem13v2 fixes.
2 Likes
I was waiting for the coreboot 4.7 release (which was supposed to be last month but got delayed due to lack of time) before I update the script/build and make a new release of coreboot for the librems. I donāt want to make an update to a ārandomā commit from git then another one a few days/weeks later when coreboot 4.7 is released.
1 Like
Release early, release often 
Is it possible to flash with external programming device (such as beaglebone black as documented in other coreboot support pages.) Programming this way can set write protection and prevent certain maleware from overwriting bootloader.
An example using external programmer:
https://www.coreboot.org/Board:lenovo/x200
Is it possible to do this in Windows 10? My coreboot is corrupted and I canāt install or boot into linux it just hangs. I was only able to install and boot into Windows 10 Iām using a Librem 15 v3.
Hi @kakaroto! Now that coreboot 4.7 is out, can we possibly get a build for Librem 13v2 that includes IOMMU/VT-d support?
It would be great if my brand new librem+qubes laptop could actuallyā¦ be a laptop: on v3.2 it wonāt resume from suspend, and on v4 it resumes, but no VMs work without IOMMU/VT-d support. (So Iām stuck on 3.2 at the moment, fully shutting down and starting up the system any time I go anywhere.)
Thanks!
2 Likes
Hi @quban. We are definitely aware of the IOMMU issue (as a Qubes user myself I feel your pain) and itās a super high priority for us to add it to the Purism coreboot image. We are actively working on it and hope to have an update soon.
3 Likes
Iām a hybrid at the moment. I have a personal Librem 13v1 that was part of the original crowdfunding campaign and endorsed/supported by Qubes. It still has the original AMI BIOS as coreboot wasnāt out for it when I got it. It runs Qubes 3.2 and suspends OK.
Along with that Iāve been helping test Qubes for Purism on the newer Librem 13v2/15v3 (first on the side, now as a full-time employee) and so Iāve tested both 3.2 and the various 4.0 release candidates and saw first-hand the problems you are talking about.
@quban The main problem IOMMU seems to cause in the Qubes 4 series is in the fact that everything defaults to HVM where in the past VMs were typically running in PV mode. This means after you boot none of the VMs start because they depend on the sys-net VM which, when set to HVM mode, wonāt start without IOMMU because it has PCI devices assigned to it. Other than that it seems to Suspend/Resume OK and install OK (if you ignore the IOMMU warnings). Iāve had success in Qubes 4 by opening a dom0 terminal and changing the VMs that have PCI devices attached (sys-net and sys-usb) to PV mode:
qvm-prefs sys-net virt_mode pv
qvm-prefs sys-usb virt_mode pv
I tried this on a fresh Qubes 4.0rc3 install and once I rebooted my VMs came up fine. Now itās true that you lose all of the security benefits of IOMMU in this case, but at least the VMs run and it suspends/resumes. Also, this is just a temporary workaround until we complete IOMMU support.
3 Likes
Is it okay to boot Debian from USB in order to flash build_coreboot.sh or would you discourage that in order to avoid a brick?
Sure, you could do that, although Iād suggest booting PureOS in live USB mode instead, since thatās what I tested but as far as I know, PureOS and Debian are pretty much the same.
1 Like
Iām happy to announce we have successfully added IOMMU (VT-d) support into our coreboot image:
https://puri.sm/posts/qubes4-fully-working-on-librem-laptops/
We are finishing up testing and cleaning up the code a bit, and then we will publish it so you can update.
6 Likes
Step by step guide with pictures will be appreciated by most
1 Like
Iām hoping to see officially supported instructions for setting up coreboot with the TianoCore payload.
Hey everyone!
The build script was just updated to build the newest update to coreboot. The Changelog.txt shows what has changed, with the most important/requested feature being the support for IOMMU/VT-d for all of you Qubes 4.0 users out there. The new image also adds TPM support for those of you who ordered the machine with the TPM module installed.
Iāll update the first post in this thread in a couple of days (I canāt edit it now due to a time limit for edits in the forumās configuration), but the main changes to take note of is that thereās a new dependency that was added : python2.7. The image version is now ā4.7-Purism-1ā.
There should be a blog post soon that explains this release with a little more details.
Enjoy!
4 Likes