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:
- Threat modeling and explanation of inner workings of Heads
- Threat modeling and reasoning of replacing UEFI DXE under linuxboot
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.