Something is not right how GitHub handles PR merging.
Please have a look here: Dasharo (UEFI) v0.1.0 for QEMU Q35 by maheshtammisetti · Pull Request #44 · Dasharo/edk2 · GitHub - all commits signed.
But as soon as they landed on target branch after merging, the Verified label disappeared: Commits · Dasharo/edk2 · GitHub
We will investigate it to avoid such issues in the future. Thanks for noticing it…
Ah, well at least you guys responded very quickly xd
And yeah, I will definitely raise it with you guys in the future. In fact, I was going to report that later. I have quite literally just found out about the git signing stuff when I was arguing with @kindagreen, I wasn’t aware of Dasharo at all until he brought you guys up.
@TommyTran732 We have a very interesting discussion on Dasharo Matrix. It looks like it is partially the fault of Github and its policies for doing rebase merge. We are trying to realize the best options for our repos to minimize confusion and improve trustworthiness.
@renehoj Pinging you here since you brought this up.
BootGuard is needed to ensure the firmware is actually from the OEM. It is the root of trust. Qubes’s security is basically useless if you end up getting malicious firmware running on there. You can read Intel’s whitepaper on it if you want.
I read the discussions you linked and they are not helpful at all. Most of it devolved into conspiracy talk, and is not what I am interested in. I see that you are a Purism customer, and I also (very stupidly) bought a Librem 14 a few years ago when I was younger and more naive. It is the worst purchasing decision I have ever made, security wise. @unman already touched a bit on why they are bad - but I will expand a bit on what he said here.
Regarding firmware updates
Proprietary firmware exists on your devices, whether you like it or not. You have 2 choices: Either you ship the updates with security fixes, or you don’t and suffer from publicly known vulnerabilities.
The FSF advocates for an absolutely insane approach where the OEM/OS vendor does not ship any firmware updates at all, and actively keep the user ignorant of the fact their computer is vulnerable so they do not update the proprietary firmware for their vulnerable hardware because of “freedom”. Purism is fully aligned with this insane ideology.
Case in point: you are not getting any sort of firmware updates on these devices except for the boot firmware (PureBoot) and the EC firmware. Qubes does attempt to load in microcode updates, but I am not sure/have not checked whether this actually does anything or not, considering the boot firmware can prevent the microcode updates from actually taking effect (Libreboot used to do this).
Outside of Qubes, PureOS is also an absolute disaster. Like I mentioned before, Purism does not participate in LVFS, so you are not getting any firmware updates from there. Even worse, they ship Linux-libre, which surpresses kernel warnings about vulnerable cpus and out of date microcode. I am not even sure if you can load in the microcode updates with this kernel or not. If you use PureBoot (as opposed to their Coreboot + SeaBIOS), you are definitely not getting the microcode updates their either.
They advertise insecurities as a feature.
This even gets more insane on their Librem 5.
Regarding HEADS/PureBoot
Technical wise, I do not fully understand how HEADS work, especially on a Librem laptop. The TPM is supposed get measurements firmware compare that to the key, but what is stopping the firmware from falsifying values to the TPM? Where is the CRTM supposed to be? I am not sure if it’s part of the ME or if it’s part of the BIOS unless AMT is present. Either way, their CPU is non-vPro and they cripple the ME, so it’s most likely in the BIOS. I could be wrong, but the explanation on how it works doesn’t make any sense to me.
Regardless, even if we take the premise that PureBoot does work (which I HIGHLY doubt), the usability of HEADS/PureBoot is terrible. Like Qubes AEM, you need to keep track of when dom0 gets updated, because if you don’t, you would have 0 idea if a warning is there because of actual tampering or if it’s just an update. It’s a hassle.
Then it gets even worse - the pairing with the NitroKey is done via HOTP. HOTP gets out of sync quite often, and I have had it gotten of of sync on my Librem and giving a warning when no updates or tampering actually happened several times.
So in reality, when I get a warning, I have no clue if it is because I installed an update and forgot about it, actual tampering happened, or the thing just got out of sync.
Oh, and this is not to mention, for this to even be secure, I need an external computer which is actually secure to even download the ISO, put it into the USB stick and flash the update. If I used Qubes to download it and the VM somehow got compromised, I will quite literally be signing malware and flashing it into the BIOS chip. This way, a compromised VM/OS can escalate into a full BIOS compromise, and the only way to get out of it is to open the laptop up and reflash the BIOS with a programmer.
To add insult to injury, this payload does not support legacy ATA unlock at all, and I am not sure if it will even work with OPAL’s shadow region for unlocking considering that it is just the Linux kernel trying to boot stuff. Normally I would not fault the firmware too much for this, but in a design like a Librem it is extremely problematic for the reasons I will explain below.
When unlock a drive with LUKS/dm-crypt, the encryption will be stored in computer’s memory. If there is a physical attacker who can get to your RAM, they can get extract your encryption key from there. To protect your drive encryption key and a bunch of sensitive stuff in memory, you would need TME.
If TME doesn’t exist, you can at the very least try to protect your drive encryption keys with OPAL (the drives’ self encryption). Too bad, the HEADS payload does not work with it, as mentioned above.
This, however, is not the end of it. It gets much worse…
UNFUSED CPU
Yes, Purism once again advertises insecurities as a feature.
Conclusion
I really do not like how HEADS work, and my experience with it (in the form of PureBoot) has been terrible. Using HEADS also means that you can’t have Boot Guard or UEFI boot, so it is useless for most modern systems anyways. Even Linux now is trying to setup some form of better boot chain with systemd-cryptenroll, systemd-measured, and whatever. Those certainly will not work with HEADS.
The Librem laptops are as insecure as it gets. The only thing more insecure than it are the Thinkpad X2xx and T4xx. I have no idea why these terrible laptops are so widely recommended in the Qubes community. I cannot in good conscience tell anyone that it is even remotely “secure” hardware. My very, very expensive $2000 Librem 14 just sits there doing nothing, as it is not trustable hardware or software, and I bought it based on emotions (yes, I went through a brief FSF worshipping phase) instead of rational thoughts. I am not sure if I can even sell this for $500 to anyone who is aware of how absolutely messed up it is. And if I don’t tell them about all this stuff - well, it is as if I am scamming them. But seriously, I just want to get rid of this horrendous hardware, get a fraction of the money back so I can save towards buying a Dell Latitude/Precision or something.
I disagree. The root of trust is the intel keys that load the initial bootloader/ME/…
Those are signed by Intel keys that are in the cpu. OEM Key for the boot guard and it just verifies later components(typically bios). If you don’t have it - your other components are insecure, BUT that in no way undermines ME firmware and services it provides, which is what makes AEM still effective (with the limitations listed)
you can still supply uncrippled ME image from somewhere I imagine (you will have to compile it from some other laptop spi image bits I imagine).
Now none of this is for the faint of heart!
That said running on completely unfused CPU is a very bad idea from security perspective and here we fully agree.
I think fusing your own keys brings you a little bit of extra protections even if you don’t actually audit the firmware you sign just because you are in control of WHEN something new gets introduced and just depend on herd immunity wrt when there are backdoors/bad code introduced in firmwares so you avoid these. This is better than all those people on MSI laptops, before the key leaked you would have probably argued that they had bootguard and were fully secure. Then the key leaked (it was probably out in the wild long before it was noticed too!) and it was totally out of your control, but now you cannot trust the machine anyway. At least with your own keys you have some control here.
In the end I just want to again remind you that bootguard is not panacea either, there are attack vectors that let you bypass it (and an earlier root of trust). So you just have to consider your threat model and mitigate accordingly.
The article you linked is for 7th gen intel, it’s not relevant anymore. They only HAP disable ME, and it’s been like that for years.
You made that point many times and it doesn’t get more impressive by repetition. I’m doing this for years. I know when dom0 gets updated. I read which packages got updated. I never once was surprised by a warning. When that day comes, I’ll trash this laptop.
So how does that happen? I’ve never seen it get out of sync and I boot/measure at least once a day for years. The only way it get’s out of sync is if you made it out of sync intentionally or a compromise.
So how does that happen? I’ve never seen it get out of sync and I boot/measure at least once a day for years. The only way it get’s out of sync is if you made it out of sync intentionally or a compromise.
It can happen just by booting without the librem key inserted too many times.
And it doesn’t even take that many times - It’s less than 10 times. If you want I can record it for you.
You are right. Quite annoying that the post advertising it is still up, but to find out the info about the current gen you gotta go the forum. With that said, thank god it’s just the HAP field and the ME isn’t actually crippled.
Sorry for my many edits as usual.
That one is true, was filed since users reported the issue, while I’m still not comfortable removing the counter increase, as documented here upstream: HOTP : do not increment counter when HOTP USB Security dongle is not connected ? · Issue #1266 · linuxboot/heads · GitHub
I have not yet myself validated threshold in upstream hotp-verification code to verify for sure if it’s a 5 or 10 counter difference that is tolerated but consider it a opsec issue in itself from end user. Who would want to boot without validating HOTP (firmware integrity attestation) more than 5 or 10 times is still unknown to me. What is the use of a security measure if its bypassed willingly over and over??
For the rest of the misinformation regarding Heads in current thread, i’m currently refraining putting the effort to clarify once again, since those concerns were addressed upstream and in other posts, even here in this forum.
I see different perspectives on trust, trustworthiness, what is considered secure in direct opposition with the concepts of ownership and auditability of what is trusted vs supply chain issues and actual security fiasco (the real security theater being at play). All of which relates to threat modeling and risk assessment.
Delegating trust seems to be the issue to debate here, outside of microcode/blobs openness and EOL issues which lead people to delegate trust into blobs for lack of better/affordable/available options. Mixing all of those concepts is dangerous, at best. Facilitating ownership should be the place for collaboration here. Pushing upstream for compiled binaries signature should be the solution here, accompanied with reproducible builds which voids the need for trust delegation once again. Ease auditability should be the focus, not delegating trust. Trust should be minimized, and peer review should replace faith.
Some previous posts and discussions:
Difference between measurements and sealing: https://github.com/osresearch/heads-wiki/issues/116
Explanation about Heads security mechanisms: Is Heads necessarily more secure? - #6 by Insurgo
Why secure boot is not necessary better: Frequently asked questions (FAQ) | Qubes OS
Legacy boot vs UEFI only and plan of deprecation dismissed: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal) - devel - Fedora Mailing-Lists
I have not yet myself validated threshold in upstream hotp-verification code to verify for sure if it’s a 5 or 10 counter difference that is tolerated but consider it a opsec issue in itself from end user.
I said it was less than 10 because I just checked with 8 times and it gave a warning. It’s likely 5 like on the GitHub issue.
Who would want to boot without validating HOTP (firmware integrity attestation) more than 5 or 10 times is still unknown to me. What is the use of a security measure if its bypassed willingly over and over??
Normal UEFI secure boot doesn’t have this issue.
As for why the machine is booted over 5 times without HOTP - who knows. Someone might skip it a few times because of inconvenience or if they just forgot the key. The problem here is that that warning on boot can be anything - be it real tampering, an update, or just HOTP getting out of sync.
Pushing upstream for compiled binaries signature should be the solution here, accompanied with reproducible builds which voids the need for trust delegation once again. Ease auditability should be the focus, not delegating trust.
Sure, that would be nice. I’m just saying - that’s not what’s on the Librem.
Legacy boot vs UEFI only and plan of deprecation dismissed: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal) - devel - Fedora Mailing-Lists
Legacy boot will go away at some point. The new stuff being described in Poterring’s blog (0pointer.net) needs systemd-boot, which in turn require UEFI.
You have read about linuxboot? UEFI security fiasco? Keys having leaked? Impossibility to replace most of UEFI but DXE? The article you referred mostly talks about UEFI only supporting vfat, which is by itself nothing really rejoicing as compared to having linux drivers which has way more eyes over then UEFI. Anyway, we could drift here into so many subjects.
AEM is shifting through trenchboot for D-RTM which is good. And there is no reason why Heads would not follow, but that requires TXT related blobs. Having root of trust for measurements in CPU requires the same blobs. And those blobs permitting IBB measurements on Intel is possible from Haswell+. Otherwise, bootblock in coreboot is responsible of measuring itself and other stages up to to payload in coreboot. If that is your criticism for ivy/sandy platforms you are right. But that is not necessarily a bad thing if proper opsec is at play, which was also covered upstream under Heads and in other posts on this forum.
Heads is a “linuxboot” payload, where Heads project currently focuses more on being a coreboot linux payload then anything else, reusing a minimal linux kernel and linux standard tools in its runtime boot security policies. Heads relies on either UEFI/coreboot doing the “right thing by default” depending on available implemented platform security mechanisms to use measurements and extend them and seal/unseal secrets so that the user can type a passphrase to unlock his data in the most trustworthy possible situation (why would you trust typing your passphrase in any other scenario?). The more blobs in the platform initialization path, the more difficult it is to have control over said platfrom. Ask firmware developers. This is not rejoicing : its a struggle!
The ecosystem is moving for multiple reasons and pushes the rest of the ecosystem to move on as well. Having systems users cannot have control over is a debate on itself and might at first look like a good idea for some for convenience and I get it. But if progress means we are all becoming renters of our computing devices for a defined supported lifetime, and trust becomes synonym of faith, i’m personally not rejoiced of the possible outcomes.
One interest of Qubes OS is prevention and compartmentalization. If no new system can be natively initialized by auditable code, and we are all now celebrating security by obscurity, all delegating trust through fate, then we are kinda celebrating programmed obsolescence and we need to at least be conscious of it.
I’m a defender of ownership and reasonably secure systems. As safeboot said:
Why safeboot?
The slightly more secure Heads firmware is a better choice for user freedom since it replaces the proprietary firmware with open source. However, Heads and LinuxBoot only support a limited number of mainboards and systems, while safeboot’s objective is to work with existing commodity hardware and UEFI SecureBoot mechanisms, as well as relatively stock Linux distributions.
The ecosystem is moving. And ownership should not be a disposable concept.
An often updated reminder: Low Level PC/Server Attack & Defense Timeline — By @XenoKovah of @DarkMentorLLC
For the rest of the misinformation regarding Heads in current thread, i’m currently refraining putting the effort to clarify once again, since those concerns were addressed upstream and in other posts, even here in this forum.
What misinformation exactly? Can you please give a TLDR at least?
You have read about linuxboot?
A bit, yes. I am not aware of any laptop sold with it and have it protected by Boot Guard though.
UEFI security fiasco?
What fiasco?
Keys having leaked?
In cases like MSI, yes. That’s why I asked for a trustworthy OEM who does not have a track record of leaking keys and stuff. Microsoft and Dell seem fine from the look of it.
itself nothing really rejoicing as compared to having linux drivers which has way more eyes over then UEFI
The idea is you can have it on normal UEFI laptops, and the UEFI firmware is verified by Boot Guard.
If that is your criticism for ivy/sandy platforms you are right. But that is not necessarily a bad thing if proper opsec is at play, which was also covered upstream under Heads and in other posts on this forum.
I really do not get the logic. What threat model does this even fit in?
The more blobs in the platform initialization path, the more difficult it is to have control over said platfrom. Ask firmware developers. This is not rejoicing : its a struggle!
The ecosystem is moving for multiple reasons and pushes the rest of the ecosystem to move on as well. Having systems users cannot have control over is a debate on itself and might at first look like a good idea for some for convenience and I get it.
No dude. All I care about is not having my firmware be tampered with by either malware or physical attacks. If I can just replace the boot firmware with any arbitrary piece of software, then an attacker can do the same.
I have nothing against open source boot firmware if they are actually secure and if there is something to verify their integrity/authenticity.
defined supported lifetime
That is already the case regardless of what you do. When have devices ever had unlimited support lifetime? How are you going to update the microcode and a bunch of other firmware if the vendors do not release them? Coreboot + HEADS is not going to save you from spectre, bugs in the graphics driver, etc on those ancient Thinkpads.
One interest of Qubes OS is prevention and compartmentalization.
Yeah, and it is not going to save you from outdated/vulnerable firmware.
If no new system can be natively initialized by auditable code
Implying proprietary code is unauditable, which is not the case. But even if we were to take this premise, your system is still going to run a bunch of proprietary firmware from hardware vendors regardless of whether you replace the UEFI firmware anyway.
It would be nice if everything was actually secure, open source, audited, and reproducible. But we don’t live in that world.
and we are all now celebrating security by obscurity,
No one is doing that. This is a strawman.
all delegating trust through fate
No one is going to read everything that runs on their system. Best case scenario is auditing a few pieces of software here and there yourself and delegating trust in others to do the auditing of other stuff for you.
I’m a defender of ownership and reasonably secure systems.
Even if I grant you that Ivy/Sandy still gets firmware updates (which they aren’t, and haven’t been for years), how are those ancient Thinkpads reasonably secure?
The slightly more secure Heads firmware is a better choice for user freedom since it replaces the proprietary firmware with open source.
I care more about being actually secure first before running open source software.
You can’t buy a CPU that is in manufacturing mode and add your own OEM key?
We adressed HOTP. That security measure, based on measured boot is sealed into TPM and unsealed at boot to be validated against the USB Security dongle (if connected at boot). If you booted the device without connected it 5+ times in a row, then yes your HOTP counter on disk will be out of sync. You can then rely on TOTP on your phone if time is in sync, and simply reseal. Your TOTP code will stay the same on your phone, meaning your bootblock+ up to the payload have not been tampered with, meaning they are exactly as they were expected to be. Security vs convenience is always on a scale. If you have problems externally verifying integrity (it cannot get as easier as this seriously. What could be easier then a trusted donlge you use to encrypt/sign other stuff that is already in your pocket and take it out when you boot). The convenience/security trade off lies there. Otherwise, you rely on external signee, vboot signed by external party and or bootguard/secure boot.
Agreed that firmware exists everywhere in devices. Agreed that they must be shipped with updates for vulnerabilities. But boot firmware is still the most important. Nothing will move soon on SSD firmware openness, but boot firmware and UEFI as a solution is not necessarily a good direction taken.
As to the firmware preventing microcode to be applied in OS, I would need you to provide sources. AFAIK, libreboot (prior of their new minimal-blob policy) didn’t included microcode updates in coreboot, delegating this to the OS. Preventing microcode update i’m not aware, while again they were promoting FSF certified OS only before, which were providing linux-libre and therefore not providing blobs as per policies. We have to refrain propagating false/partially true information otherwise we are not helping anyone.
As for the reasoning behing Heads (coreboot enabled hardware with as minimal blobs as possible) and linuxboot (replacing DXE complexity under UEFI), this is a must read/must watch:
This is ideology, but ideology has workarounds as well. I see the microcode in Librems builds from coreboot stitching output and know that Purism hosts those blobs. Taking for example the librem_15v4 here on master, where blobs (fspm, fsps, microcode) are versioned and building as of coreboot 4.17 release (I do not follow tightly what they release on their side, but Heads upstream and their releases are normally not so far of each other):
2023-06-09 18:20:41-04:00 DONE coreboot
touch /root/project/build/x86/coreboot-4.17/librem_15v4/.build
# Use coreboot.rom, because custom output files might not be processed by cbfstool
"/root/project/build/x86/coreboot-4.17/librem_15v4/cbfstool" "/root/project/build/x86/coreboot-4.17/librem_15v4/coreboot.rom" print
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs_master_header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 56832 none
cpu_microcode_blob.bin 0xdf00 microcode 104448 none
intel_fit 0x27740 intel_fit 176 none
fallback/ramstage 0x27840 stage 104415 LZMA (236236 decompressed)
config 0x41080 raw 1106 none
revision 0x41500 raw 724 none
build_info 0x41800 raw 100 none
fallback/dsdt.aml 0x418c0 raw 12930 none
(empty) 0x44b80 null 548 none
fspm.bin 0x44dc0 fsp 405504 none
fsps.bin 0xa7e00 fsp 147442 LZ4 (188416 decompressed)
vbt.bin 0xcbe40 raw 1171 LZMA (4608 decompressed)
fallback/postcar 0xcc340 stage 27008 none
fallback/payload 0xd2d40 simple elf 7016094 none
(empty) 0x783c40 null 6707300 none
bootblock 0xde94c0 bootblock 26880 none
2023-06-09 18:20:41-04:00 INSTALL build/x86/coreboot-4.17/librem_15v4/coreboot.rom => build/x86/librem_15v4/heads-librem_15v4-v0.2.0-1564-g3b3c49b.rom
As for PureOS, this is an OS fitting with FSF ideology. Of course, to fit that ideology, they ship only libre software. And they have to do some workarounds to respect that contract. This doesn’t mean that firmware is not exposed and useable for the OS, but they have to do more then most OSes to respect that contract. That means having to expose firmware to the OS, so that the OS doesn’t have to and can use it being exposed readily so the OS doesn’t have to offer them. This will eventually land upstream into Heads, now under testing under pureboot for librem platforms willing testers. If you do not like PureOS, just do not use PureOS. But saying they do not provide those or work in that direction is not fair.
So to be clear, they provide the updates. But are not yet offered through LVFS, that is right at the time of writing those lines. As for microcode update, this is limited by Intel EOL, otherwise provided through coreboot and applied early at boot. For the lifetime support of a platform, it now depends on the OEM, not the manufacturer. As long as a platform is supported by upstream coreboot and/or a fork, that platform receives updates. And those updates requires to be built and delivered somehow. Mixing all of those, again, is not fair. Microcode updates can either be applied by firmware or OS.
CRTM under Heads is generally into bootblock per coreboot measured boot. There important history here, this is again an ecosystem moving consequence/result. Measured boot was first under Heads as a patch, was taken and improved as part of vboot+measured boot and then measured boot was supported without needing vboot to be activated. What this means is that the TPM (fTPM/dTPM) of a platform is initialized and used as early as possible to measure itself and the next coreboot phases. Those measurements are then in the TPM PCRs, which can only extend a PCR measurement and cannot reset the PCRs content. And those measurements are then used to seal/unseal secrets. TLDR: the bootblock under coreboot is the CRTM. Without TXT on a recent enough platform, the CRTM is under bootblock only. To have a successful tampering of a firmware being able to falsify measurement reports, the bootblock and other coreboot phases would need to be hacked to report static measurements to the TPM instead of their own real ones and be flashed by an evil maid. This is possible, but highly improbable. The problem of Heads as of now is not bootguard/secure boot non-compliance, but the lack of authentication mechanisms to protect non-authenticated users from being able to get to the recovery shell/take a firmware backup, tamper with it and flash it back into a user’s computer. If authentication was possible there, then only external flashing would make it possible to tamper the firmware, which would require taking a backup, tamper with it and flash it back. Here again, we are not talking about firmware implant that would get noticed through presently active mechanisms. The physical attack threat is still a thing for everyone. The use case for which Heads is there for is to implement a reasonably secure trust model (auditable because coreboot based and then payload and drivers being linux based with bare minimal blobs presence). The goal here once again is for the firmware to permit the user to type his unlock passphrase in a safe space, to have a recovery shell that permits him to inspect things in a trusted state. As of today, if you have a copy of your firmware image handy, you can internally reflash Heads with that ROM, keeping settings. On reboot, HOTP and TOTP would still be good, and all your worries of having left your laptop unattended would be dissolved at least on the firmware level. You trust OPAL (SED)? Just to remind you, implementations have not had a perfect score on security either and come with its own subset of disadvantages on threat modeling consideration. Again, this is not enforced through open source implementation and firmware based. The reason people trust more LUKS then opal is because the code is reviewed by more people and integrated by most and used by most. Again a different philosophy.
Heads could provide the tooling to work with OPAL, it was asked in the past, but when challenged, people decided to change their convenience/security tradeoff based decision and chose TPM released disk encryption key to the OS.
While somehow true, the disk encryption key passed from Heads to the OS through additional cpio on boot could theoritically be found using tools installed on dom0 from an attacker on a computer left alone unlocked (which again is pretty bad opsec) or through memory dumping or frozen ram and/or external dumping. Get home message: poweroff your computer prior of leaving unattended in untrusted area. Good opsec only will save your day.
I didn’t get that part. hashes are there to be verified prior of booting/flashing. Heads can boot from tails with detached signature verification as well. I take the critic of Heads not having detached signed updates, where again, the ideal would be to have reproducible builds producing the same hashes for everyone, and then having CI report those hashes and users reporting differences if any. You should always verify hashes/detached signatures prior of flashing.
If I forgot to adress something, point me to it directly. But as far as this goes, let’s just keep it simple: Heads can address quite easily adapt to a missed threat model, as long as security policies are adapted consequently. Firmware upgrades, when it comes to coreboot, are quite “easy” to maintain upstream, as long as other motherboards share code with what is upstream, and that those platforms continue to be tested across releases. A firmware is a mix of platform initialization code, done natively or through blobs, where security mechanisms are shared across multiple boards and where programmers read the code to propose changes which are reviewed prior of being merged. When we look at coreboot codebase and security issues that were found in the past, the score board is pretty near perfect because of this. When we look on proprietary firmware, the storyline is not so clear, and code is being reused and integrated in a more opaque way, with a lot of players producing different parts of the code in form of blobs that are integrated without being audited to finally arrive in the form of an UEFI update capsule. This is where “reasonably secure” comes from: keeping things minimal to produce a desired outcome with the set of security policies that are needed.
As for buggy graphics, once again this is quite untrue. Those platforms share the same i915 drm+fb linux kernel drivers, and coreboot provides native graphic initialization for GMA into coreboot (actually, those Intel chipsets are the only one supported through libgfxinit under coreboot). As of today, Heads drives graphics through linux kernel drivers. The way forward will most probably be to use native init from coreboot, which again goes with the ecosystem going forward, in the sense you tackled before. EFI initializes graphics in a unified way, through GOP from firmware to provide basic framebuffer, which recent linux kernel (5.x+) can now drive through simplefb/simpledrm much simpler drivers. The way forward on native initialized platforms will be to reuse this simpler way forward, so that Heads doesn’t have to provide those bloated kernel driver to drive gaphics either. Newer linux distro are only packing simplefb/simpledrm for OS installation, reducing the size of their initrd and delegating 3d optimized graphics on final OS installation. Again, the ecosystem is moving here, goal being to provide unified kernel for final OS, which is going to be bigger, but not a problem on recent systems where we don’t really care if our /boot becomes 2Gb. But where firmware payload size is a constant struggle to pack features in “firmware as a service” scenario.
On spectre, again we are mixing things. The last microcode updates available to those old platforms have mitigations. Some newer platforms have other cpu extensions that are vulnerable to other attack vectors that older ones didn’t.
[ 3.012404] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 3.012416] Spectre V2 : Mitigation: Retpolines
[ 3.012422] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 3.012430] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
[ 3.012436] Spectre V2 : Enabling Restricted Speculation for firmware calls
[ 3.012444] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[ 3.012453] Spectre V2 : User space: Mitigation: STIBP via seccomp and prctl
[ 3.012462] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
[ 3.012474] MDS: Mitigation: Clear CPU buffers
[ 3.012479] MMIO Stale Data: Unknown: No mitigations
I covered MMIO Stale Data and covered current state of vulnerabilities here
Under Heads, some tools are missing to ease auditability of firmware integrity (and worked on) to provide insights directly from the firmware and externally. On each Heads builds produced from CI, you can see in the artifacts the hashes of each binaries that are built, cpio constructed, initrd packed, kernel and final stitched firmware image and splitted firmware images for external flashing if two SPIs need to be flashed externally… You can as well go on the recovery shell, and extract the parts from there and inspect/verify. The idea there is to trust but have the capability to verify. If you really want to check if you can trust your bootblock as CRTM, you can backup your firmware and inspect it on another computer. You can extract the bootblock, and measure it yourself to see if the tcpa log (cbmem -L) lied to you in case of total paranoia. And as said previously, you could reduce that paranoia with trust and in case of total distrust, simply reflash the same version of your firmware, through flashrom, internally and see TOTP/HOTP still being unsealed without error and have reasonable trust that the state of your firmware is as expected. You could replay the hashes.txt file from CI artifacts or local build to make sure even the kernel modules loaded are the same as expected. Bonus, you can as well build your own kernel and sign it for yourself if you need to. Those are possible only if you keep control, if you own, the whole boot stack. Trust but verify is the goal here.
Also said previously, TXT blobs could be added into Heads (coreboot) and the bootblock could be added into IBB (what is measured by ACM blob+sinit on CPU boot, the ACM being first thing launched to measure what is part of the FIT descriptor to be measured into PCR0, which only ACM can populate). By doing so, your trust into your Librem14 would be renewed. I really encourage you to open a ticket to Purism about that. They could, unless they are not allowed to redistribute the ACM blobs themselves, which is also a possible explanation.
Unfortunately not. A lot of interesting things happened on that in the recent years from 9elements at GitHub - 9elements/converged-security-suite: Converged Security Suite for Intel & AMD platform security features. It might be time to test this on your own hardware if unfused and go forward that path. But that, also as said before, would lock you down. It will require you to sign your updates or defer trust to someone else and all the other things I keep talking about. The scale here is trusting third parties to auditing yourself the bare minimal.
Last point on LVFS. I cannot speak for Purism, but Qubes 4.2 comes with fwupd and the work to arrive there has come a long way with funded work from Nlnet (thanks again) fwupd work (3mdeb) and QubesOS collaboration and myself(tap on my own back to have pushed that forward)… Heads has a PR to be able to propose updates to the user, which qubes will put in place under /boot for Heads to pick up. But just that is a bit of a challenge, since releases need to be produced, and OEM public keys need to be added to Heads. All is possible there. But for CI to sign those firmware images and push them to LVFS, the same issue surfaces: but what if the private key leaks from CI? No. The reproducible images would need to be detached signed adhoc and that detached signature put alongside of the reproducible rom images after the fact on releases… There is no way private keys could be trusted to be put under a CI (where their security tracker stories have some issues there as well). This is why Heads is aimed more about reproducibility of builds and making it it easier for users to update their firmware images. Other companies are making it easier for those updates to be delievered to the users through subscriptions. Those things are being worked on, but it takes time and resource (time=money), which big companies have which makes things advance faster for them, also at the cost of locking the user down. The challenge here is to provide the security mechanisms needed without locking users down.
Adapting to an ecosystem that is moving without accepting to completely surrender rights to freedom. And explaining the costs of such changes so users understand that once the ecosystem completely locks things down, we will barely be renters of our computing devices, where the industry will dictate the rules, without any possible way to go back. Supply chain issues is a real problem, where opacity is the new reality. Trust but verify is to me the best tradeoff, where again, usability is the real challenge to answer convenience/security tradeoff.
I almost always forget, and i’m sorry, that people write way better then I do and that I should refer to them instead of trying to explain better then they do.
Here is a great article about Trusted Boot (vs Secure Boot and and other verification schemes), the history leading to Heads in a really skimmed and easy to read fashion: Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot) - Michael Altfield's Tech Blog
@TommyTran732, it would be great to have a live discussion during the regular Dasharo Developers vPub this Thursday: Dasharo User Group #2 - Attendize.com
I want to invite you and everyone involved here to have a real conversation and clean up potential FUD and misinformation regarding security. We could start with a 10min sum up of this thread and continue with the usual vPub flow (20min Q&A and 30min open discussions). Who is in?
I’m in and I will talk a bit about our roadmap. NovaCustom and Dasharo have built a great and open base and it’s time for the next step to get our laptops more and more secure. Let’s discuss all possibilities tomorrow to achieve our goal. Don’t miss it!
I second @pietrushnic 's invitation 
Everyone @here is welcome to our joint DUG #2 + vPub v7 event: DUG starts 2023-07-06T16:00:00Z (your local time) and shifts to vPub opensource online party two hours later! 
More info and Join links: