Fri, Sep 6
Understandable and I don't intend to be rude or disrespectful. I have read other posts where this particular request appears to be parked repeatedly. I'm at a desperation point and only intend to imply the desperation and not to offend anyone or hurt anyone's feelings.
I don't think this is the way to request for support Please be kind and read other issues related with your problem first.
Thu, Sep 5
Apr 17 2019
I'm not sure what vboot is, but if we're talking about Intel Boot Guard, it's my understanding that requires physically blowing fuses within the CPU, that then only allows signed UEFI to actually boot/run.
Mar 11 2019
Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control
Sep 30 2018
Oh and btw. how do you intend to detect tampering anyway? Please don't tell me you need a Librem Key. Purism tries to sell the laptops as secure and not secure-with-additional-hardware, right? Or is the Key now part of the laptop shipment? If not, what is your security goal for a humble users without Librem Key?
You seem to be trapped in the thinking that signature verification is bad and measuring is good. Please don't see it like that. They both complement each other very well.
Sep 27 2018
We do not need or want it. Specifically the problem with systems like vboot (and why we went with Heads instead) is that we do not want to require that the BIOS pass a signature check against a key that we control. We want the user to be able to flash with a custom BIOS if they so choose, even if we haven't blessed it with our signature.
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
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 15 2018
actually, you'd want to change the link to use the latest commit hash, not master, otherwise the script will break again next time the microcode is updated. So instead use:
Jun 1 2018
I confirm I haven't been able to reproduce the bug after weeks of usage.
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.
Feb 25 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!
Can we close this one?
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> 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.
After discussion, removing the PureOS tags as we don't want to risk tainting PureOS with the remaining proprietary software in our coreboot firmware. This project will remain on the coreboot side.
Given most of the work for this is not coreboot work, but PureOS work integrating an existing firmware image (which we'd treat as a binary blob) with fwupd, I don't know that this is really a coreboot project as much as a PureOS project.
Jan 29 2018
Oh yeah, here's the changes needed to enable SGX (over commit id 65d2754e1aaa4e90059b65fac3c00d847e2e465f) :
Dec 1 2017
Oct 30 2017
Oct 22 2017
Oct 16 2017
Patches have been cleaned up and pushed to gerrit.