Sounds as one can not wish for much better.
I’ve found out just now that you can simply do sudo apt-get install purism-librem-coreboot-updater
to install all the required stuff for flashing.
@vv01f, if you want to try (standard disclaimers applied), here’s what you need to do:
- boot with
iomem=relaxed
if you run kernel 4.9 and later sudo apt-get install purism-librem-coreboot-updater
- download this script: https://github.com/purism/purism-librem-coreboot-updater/blob/master/purism-librem-coreboot-updater.sh, make it executable and run as root
- follow instructions provided by the script
My coreboot installation attempt went fine, without errors.
The librem 13 v1 coreboot image is ready and you should be able to give it a try by doing as @mladen suggested (the iomem=relaxed
boot option or boot into the old 4.7 kernel if you still have it on your boot menu) then run the script.
The one that gets installed when you do sudo apt-get install purism-librem-coreboot-updater
is I think outdated, but you’d need to install it so it can bring all the dependencies with it.
The reason that this has not been publicly announced yet is because we need to go through a round of beta testing first, just to be extra sure there are no issues. I was also caught up on testing NVMe support which seems to be working fine apart from one user (who is also having issues on the original BIOS, but I don’t know if it’s a problem with his NVMe drive or it’s something that can be fixed in coreboot).
The librem 15 v2 coreboot port is not yet done, as it was a higher priority to get the latest hardware working so they can be shipped with coreboot preloaded on them. But I’ve learned so much in doing these ports that I don’t expect the L15v2 port to take very long (probably a day or two).
thx @kakaroto for the update on the current state. this kind of information was what I missed in the blog post. looking forward to recommend the librem to more people also linking to this.
The process was extremely easy and flawless.
Thank you very much.
I am very happy to finally get rid of ME and the BIOS.
Glad to hear it, let me know if you get any issues, especially if you have an NVMe.
Thanks!
Wow, if one day there would be coreboot for the L15v2, that would be just amazing! Actually, I’d already given up all hopes, now I’m dreaming again!
On a side note for those not running PureOS: on new kernels, there is a new safety feature that forces you to recompile your kernel in order to be able to flash the bios. Since the encrypted partitions support was buggy (at least in Debian), that means that a newly compiled kernel can not support your encrypted partitions. As you’ve guessed, that makes it a complete mess. So the easiest option might be to keep a PureOS partition for this purpose.
The build script was updated to add Librem 15 v2 support, which has finally been ported, so yeay!
Hi, great news for us !
Now, how can we apply it over the original AMI BIOS ?
If I’m not mistaken, the current script needs to be applied over an existing CoreBoot.
Will the purism-librem-coreboot-updater.sh script work this time ?
Humm… that’s a good point, I hadn’t thought of that and thanks for bringing it to my attention. No, the purism-librem-coreboot-updater hasn’t been updated yet (and won’t be for a few more weeks as there’s a lot of work needed on that script before it’s ready) and looking at the build script, it indeed expects coreboot to be already installed otherwise it doesn’t work. What I used during my testing was a librem 13 v1 coreboot image and I select the “Extract from a pre-built coreboot image” option in the script.
If you can hack around the updater script to make it build the librem 13 v1 image (and NOT flash it), that would work. Otherwise, I guess you have to be a little more patient while I sort out this mess.
Ah, good idea.
I happen to have access to a L13v1 which has already been updated to coreboot. (may need an upgrade)
I will try that way, probably in the weekend.
Well, I must say that the CoreBoot update of my Librem15v2
is a SUCCESS !!!
I was a bit scared before launching the flashrom command, but what a relief to see the Purism logo at reboot !
The idea to start with the L13v1 coreboot dump was good.
The only thing, due to a SHA mismatch, I had to manually copy the extracted vgabios.bin to the blobs dir.
The build_coreboot script then happily constructed a new coreboot-l15v2.rom
Now I need to change the boot order to have it boot from nvme instead of hdd…
T.
Without either a Librem13 or the binary blobs, I could obviously not test CoreBoot on my Librem15v2. But at least, I have some initial feedback:
* if no git user and email was configured, the script fails (some files are missing, so building the cbtools fails with a missing include). It would be nice to at least warn the user to do so before running the script. For those who ended up with such a failure, the git checkout has to be deleted before running the script again (otherwise, it still fails);
* for those of us not having anything to extract the binary blobs from, don’t you think that Purism could provide the said binaries? In terms of security, this is not worst than the current situation (since the same stuff is already packaged into the AMI Bios, so if Purism wanted to mess up with us, it would have already been possible). That could be a temporary solution at least, until something better gets set up.
Mathias
PS: since I am using Debian and since flashroom is a not usable without a special kernel, I created a temporary PureOS partition to prepare and install Coreboot. Therefore, I had not already defined a git user…
Note for anyone reading this thread who wants, instead of an update script, a script that will build the latest version of Coreboot for their Librem from scratch, there is one here.
You can simply boot into PureOS live and to th update from there.
Please could you expand on that? This is the first time I have heard anyone assert that flashrom requires a special kernel. Is this something unique to Librem hardware?
No, this is not specific to Librem, this is because of the CONFIG_IO_STRICT_DEVMEM kernel option (for example, see https://libreboot.org/faq.html#flashrom-complains-about-devmem-access). It was for a while possible to pass the iomem=relaxed kernel command line argument but on newer kernels, this command line argument is not supported anymore (as it could be used as the first step in an attack). Unless this has changed again, you would have to recompile your kernel in order to allow flashrom to operate…
Thanks for the explanation!
As an aside, I am trying to understand the rationale for this kernel option. In order for an attacker to use Flashrom to perform internal flashing, they would have to have root level access. But if they have root level access, then they can modify the kernel to disable CONFIG_STRICT_DEVMEM
and CONFIG_IO_STRICT_DEVMEM
. I suppose the need for the attacker to do that, and perhaps also to reboot the computer, has the benefit to the defender that these extra steps would slow the attacker down and make their attack less stealthy.
The issue isn’t one of security, it’s one of licensing. Coreboot on broadwell systems only works with an “MRC” binary, which is only created by Google for their chromebook machines. The file isn’t available for download publicly and it’s not licensed so it can be redistributed by us. So basically providing those files would be equivalent to ‘piracy’ (copyright infringement) or at the very least a license violation. That’s why we don’t and can’t provide those files and that’s why we instead provide a script which will download the chromebook recovery image directly from google’s servers and extract the coreboot image in it, then extract the MRC file from it.
As far as I know, flashrom works fine with recent kernels even without the iomem=relaxed option. I haven’t seen any kernel versions in which flashrom doesn’t work (either with iomem=relaxed or without it for recent versions).