Kyle, can you evaluate vboot in terms of security, do we need it, do we want it and all that.. so we can decide if we want to add it or not

Bump. @zlatan.todoric any ETA on how soon can this be done ? @mladen.pejakovic needed to use flashrom yesterday and it wasn't working because it's still outdated, and I realized this hasn't been fixed yet.
Thanks!

I fixed it by using the old commit hash for the previous microcode. I didn't want to update the microcode since that would mean changing the version (so, changing the config, adding a new tag, rebuilding all, changing coreboot final hashes, changelog, etc..) and I'd like to do it later when I update the FSP for the skylake ones as well, but that one needs testing first and I wanted this fix to be out asap.

Humm.. I thought that repo was meant to contain an archive of all microcodes, I didn't realize he deleted old ones when new ones are out.
I'll update the link and use the commit hash, I prefer that than having the script break constantly.

Sure, I have no idea how you guys do things, so I'll just assign it to zlatan as suggested. Thanks.

Can someone follow up on this ? That request says "it doesn't have huge changes but it would be nice to have it" is actually wrong since this v1.0 release actually adds Skylake support which is definitely a must-have rather than a nice-to-have feature. (At least for us).

Yes, I know that, but I meant you don't need to build an actual coreboot image, just the utils that come with it.

Yes, it still is required (and it's not handled by the coreboot team). The source package might be 'coreboot' as stated above, but the binary package that I need updated is 'coreboot-utils'.
Thanks

I think the issue was found and resolved and tests by Francois haven't been able to reproduce the problem, so i'll consider this done.

Note: package is coreboot-utils

It's fixed, and tested. Make sure you delete the flashrom directory so it gets checked out cleanly (rm -rf coreboot/flashrom/) then retry, it should work now.

Yes, it's a library dependency (libusb) while flashrom is being compiled by the script. It's unrelated to the kernel (though the kernel also uses libusb and is affected by the same issue).
It looks like this was fixed in flashrom 11 days ago and the commit is here : https://review.coreboot.org/cgit/flashrom.git/commit/?id=291764a70e6d8b212680e311bfb0825abf2b9a2f
I'm now testing it and I should have it fixed and the script updated within the hour.

I don't think the patch to the kernel is relevant here since coreboot has nothing to do with the linux kernel. I think the patch needed has to be on the flashrom project itself. I'll have a look and see if that was recently fixed upstream, then I'll update the flashrom we use in the build_coreboot script, and test it.

From customer email :

Intel SGX is a technology that provides protection of predefined secrets even in a case of system compromise by creating SGX enclaves. I currently need to run several projects that makes use of SGX on the librem and that's why I need it enabled.

IT's done for l13v2 and l15v3, need to add the iommu patches for broadwell in the branch and test it for l13 v1 as well

Yep, and we will very gladly do so! thanks for the reminder!

<avph> KaKaRoTo: does purism have any plans on using vboot btw?
<KaKaRoTo> avph, I'm not familiar with it, so I never looked into it. I was asked that same question last week and I opened this task for it : https://tracker.pureos.net/T315
<KaKaRoTo> it's mostly about "what is it? what is it for? do we need it? can we enable it ? etc..."
<KaKaRoTo> avph, so if you're familiar with vboot and want to give us some pointers on that, I'd appreciate it
<nico_h> mostly for a secure update mechanism
<nico_h> so not every malware can write to the flash chip
<avph> well it won't run the malware mostly :)
<nico_h> um, scratch the latter
<KaKaRoTo> nico_h, how does it achieve it? needs a portion of the flash to be read-only, no ? does it use an IFD region for that ?
<KaKaRoTo> does it require a TPM or is it a way to get verified boot without TPM ?
<nico_h> Google uses the write-protection feature and /WP pin of the flash chips
<nico_h> I'm not sure if it requires a TPM (I think only for downgrade protections or something)
<avph> KaKaRoTo: no read only is (or can be) achieved with southbridge registers. TPM is to prevent updates rollback but the secure boot and safe updates are still there
<KaKaRoTo> /WP pin of the flash chip with protect the entire chip, not just a portion of it
<nico_h> no, /WP pin to protected part of the flash chip
<nico_h> usually, /WP only protects the block protection setup of the chip not the whole chip
<nico_h> but... that depends on the chip
<nico_h> KaKaRoTo: the general idea is: 1. have one part RO during runtime (can be achieved with early programming of PCH registers, as avph pointed out). 2. the RO part only runs other (updated) parts if a signature verification worked out
<KaKaRoTo> ok
<KaKaRoTo> I assume the early programming of PCH registers is done by vboot itself already
<avph> not sure but certainly saw stuff like that
<KaKaRoTo> I have this in my TO-READ list, so I'll explore that more later : https://www.coreboot.org/git-docs/Intel/vboot.html
<nico_h> unlikely, as it's mostly only used on chromebooks with the /WP thing

You won't taint it because this task/project is about writing a bash script, there's no proprietary bits in the bash script itself. Unless it's about the FSF requirement and the fact that the script itself will manipulate a binary file? Somehow I'm not sure that's a valid reason, considering that the librem-coreboot-updater script is already in PureOS and this task is about porting that script to the fwupd system
Either way, whether it's tagged PureOS or not, a PureOS developer is still probably the best person for the task here.

Oh yeah, here's the changes needed to enable SGX (over commit id 65d2754e1aaa4e90059b65fac3c00d847e2e465f) :

The format was reverse engineered by PT at Blackhat 2017 : https://www.blackhat.com/eu-17/briefings.html#intel-me-flash-file-system-explained

It's been merged, so yeay!
https://github.com/corna/me_cleaner/pull/70

Considered fixed.

Thanks a lot @habs for the contribution. I never did that because I also couldn't figure out proper docs on what those 4 PCI IDS should be., but it feels to me like it can be any PCI device on the machine, I just didn't think that they would uniquely identify the librems. I'm now realizing that uniquely identifying via PCI is not needed, but it rather needs to identify with PCI + dmi information, so it's fine as is.
I tested your patch but unfortunately it didn't work, because the ISA bridge doesn't have a subsystem id, so the pci id that worked for me is : {0x8086, 0x9d48, 0, 0, 0x8086, 0x1904, 0x8086, 0x2015}
Did you send the patch to them via gerrit or do you want me to finish it (add the info for librem 13, and for the previous revisions?) then send it in one commit ?

@nicole: SeaBIOS will boot from the M.2 and I think linux will assign 'sda' to the HDD it boots from, no ? If you have a linux installed on the 2.5" and you boot on it, the 2.5" would be seen as "sda" in that case, no ?

Patches have been cleaned up and pushed to gerrit.

Done by @MrChromebox

Fixed by @MrChromebox via FSP2 SATA speed limit option.

Done by @MrChromebox and to be merged upstream soon.

Done, and tested.

Humm, ok,well, it's not intuitive because it asks for confirmation *after* it already repartitioned the disc (and yes, even without reformatting it's bad), but I guess it can be closed since technically, it's OEM and it shouldn't be running on a machine which is not meant to be wiped.. but in that case, just drop the "hdd already has a partition, are you sure you want to delete?" prompt since it's useless.

Note: I got it working on the Librem 15. I removed the /etc/modules.d/purism-psmouse.conf and did modprobe -r psmouse && modprobe psmouse, that fixed the multitouch. Note though that on reboot, I had to do the modprobe again because it was loaded with the wrong options by default even if the /etc/modprobe file wasn't there.

My current librem 13 v2 prototype has a fried touchpad, once I receive the final hardware, I'll be able to test and provide proper logs. For now, all I can say is that MrChromeBox who tested it on his prototype said that mouse scrolling/multitouch doesn't work in PureOS but works in GalliumOS. Also, when he tried to remove psmouse module then re-insert it with proto=imps, he said that it broke scrolling in GalliumOS.
The logs I have from before the mouse was fried had this in dmesg :