User Details
- User Since
- Dec 2 2016, 07:44 (418 w, 5 d)
Sep 27 2018
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
Aug 13 2018
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!
Jul 16 2018
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.
Jul 11 2018
Sure, I have no idea how you guys do things, so I'll just assign it to zlatan as suggested. Thanks.
Jul 10 2018
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).
Jun 4 2018
Yes, I know that, but I meant you don't need to build an actual coreboot image, just the utils that come with it.
Jun 1 2018
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.
May 28 2018
Note: package is coreboot-utils
May 23 2018
May 22 2018
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.
Feb 24 2018
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.
Feb 23 2018
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!
Feb 7 2018
<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
Feb 5 2018
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.
Jan 29 2018
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
Dec 1 2017
It's been merged, so yeay!
https://github.com/corna/me_cleaner/pull/70
Considered fixed.
Nov 23 2017
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 ?
Oct 30 2017
Oct 16 2017
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.
Oct 10 2017
Sep 14 2017
Sep 8 2017
Sep 5 2017
Aug 31 2017
Jul 26 2017
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.
Jul 6 2017
May 20 2017
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.
May 19 2017
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 :