Thanks for clarifying.

Thanks for clarifying.

Thanks for clarifying.

@jonas.smedegaard not an issue, the script in question is deprecated, and it's not part of PureOS (nor should it be)

@jonas.smedegaard no to both

@jonas.smedegaard no to both

@MrChromebox Is this still an issue, and is it tied to PureOS?

@MrChromebox Is this an issue, and is it tied to PureOS?

@MrChromebox Do you know if this is still an issue, and if it is tied to PureOS or (as it seems to me) to Purism firmware flashed onto laptops and possibly published directly by Purism as package as well but not shipped with PureOS)?

@kakaroto Is this still an issue?

@kakaroto Is this still an issue?

@kakaroto Is this still an issue?

Is this still an issue, now almost 4 years later?

According to https://tracker.pureos.net/T315#10888 this feature is unneeded and unwanted in PureOS.

Nicely done -- installing on your Mac is pretty cool. :-)

https://nabeards.com/posts/pureos-install/

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.

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.

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

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.

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

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.

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:
https://github.com/platomav/CPUMicrocodes/tree/956244154c87316e4e6162f02b17cf3547597b1a/Intel/cpu306D4_platC0_ver0000002**B_2018-03-22_PRD_0B0DD00D**.bin//

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.

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!

Can we close this one?

<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.

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.

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

Considered fixed.

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.