I am in need of a new laptop to run Qubes OS and I need your suggestions. The goal is actually have good hardware security instead of worrying about conspiracy theories like how the IME/PSP are magical backdoors and whatnot. I have looked at the Community-recommended computers - User Support / HCL Reports - Qubes OS Forum (qubes-os.org) page and all of the recommendations seem very bad.
Ideally, the laptop should have:
A reasonably new CPU (Intel 10th gen or above would be great!). Skylake CPUs went end-of-life last year will no longer get microcode updates. This rules out all of the Thinkpad X2xx and T4xx computers, as they have gone end-of-life a long time ago.
Support for custom UEFI secure boot key enrollment and a drive with proper OPAL implementation. At minimum, if the drive does not support OPAL or is known to have an improper implementation, I need to be able to replace it.
Firmware updates available via LVFS.
TME/TSME support.
Proper BootGuard setup. The computer should not be running arbitrary firmware that gets flashed onto the BIOS chip, as the case with the Thinkpad X2xx and Librem laptops. Laptops with leaked BootGuard keys such as the MSI ones would also not be acceptable.
CPU NOT in manufacturing mode. Kind of crazy to even bring this up, but looking at Purism’s own posts they essentially seem to cripple the ME, not setup BootGuard, not blowing the fuses, and ship the CPU in manufacturing mode because otherwise it wouldn’t boot. This seems so, so bad, and I am not sure where or what the root of trust on a Librem machine is.
Nice-to-haves:
Secure Core certification, in case I decide to use Windows later on. Having proper hardware support for Windows security features and not having to deal with the Microsoft Third-party CA would be awesome.
Intel TXT and TPM 1.2 support for Qubes AEM. I probably won’t need this, since the plan is to use OPAL with a signed UEFI image in the shadow region, but it would be nice to be able to play with it.
Not needing out of tree kernel modules / drivers to get things like Wi-Fi working. It’s not a big deal on Qubes OS as it would probably affect a few VMs; however, I absolutely do not want to deal with this if I ever decide to use a normal Linux distribution, as I would not be able to put the kernel into lockdown mode.
Actually good open source firmware - something along the lines of Coreboot + Tianocore/EDK2. I am not interested in using open source firmware just for the sake of it - stuff like Coreboot + SeaBIOS or Coreboot being flashed after-the-fact because the OEM didn’t setup BootGuard properly is a no go. Not supporting Secure Boot at all like System76 is also a no go. If such a thing isn’t available, it’s okay. I would rather go with an off-the-shelf proprietary UEFI firmware than a broken open source one.
Notes:
I am aware that Qubes does not have proper LVFS support at the moment. I will probably need to find some other ways to actually update the firmware. With that being said, I would prefer that the manufacturer actually attempts to distribute updates via a proper channel than adopting an “out of sight out of mind” model where they will literally just not ship any proprietary firmware update at all like Purism.
I am also aware that the IME increases the attack surface, but I don’t think entirely crippling it and all of the security features it provides (BootGuard being one of them) like Purism does is the way to go.
There are not a lot of companies selling laptops that can run Coreboot, System76, Purism, Starlabs, Nitrokey, and NovaCustom are the only companies I know of.
Which security features relevant to Qubes does it provide? Can you give any link explaining how BootGuard would help Qubes and why it’s better than Heads?
I imagine at least in theory working boot chain of trust (when you hold the keys) means Evil Maid is not even a concern. The Evil Maid can replace the early bootloader or later components and the end result is just that it won’t boot at all.
AEM (And eventually Trench boot) is just a poor man’s implementation that depends on a “human-based TPM” where a human at every boot acts as a guardian to ensure the boot is not compromised by looking at messages printed. (various detached boot schemes is another play at this where the external boot device is (an additional) externally held secret) with all the limitations this entails listed in the AEM documents like shoulder surfing, human error and whatnot.
Depending on particular implementation details there are various holes in all these approaches though. It was demonstrated that you can subvert TPM and early boot checks with various hardware attacks, which would affect AEM and bootguard respectively. That does not mean your run of the mill Evil Maid would be able to execute those attacks, but if you are a high profile enough target… Then again the xkcd about encryption probably applies in that case too.
BootGuard and Secure Boot are two different technologies, Secure Boot is AEM and BootGuard prevents the UEFI firmware from being modified without access to the signing keys.
AEM is definitely not “secure boot”, secure boot is just making sure your OS image is signed before the bootloader ((uefi)bios in pc speak) hands off control to it.
Interesting. They advertise a custom firmware based on Coreboot, but I can’t seem to find out what payload it uses. “Coreboot” alone doesn’t mean anything, the payload matters a lot.
The CPUs they offer are non-vPro CPUs, so are things like Intel TME even available? This is important, as things like your dmcrypt key will eventually end up in RAM, and memory encryption helps a lot against cold boot attacks.
They do not seem to be participating in LVFS either. How are they shipping firmware updates?
You flash the ROM using the internal programmer, either you download their ROM or you compile it yourself, you can flash from a Linux livecd or use their update suite. If you have a paid subscription you can PXE with a Linux from the boot menu and update from internet.
This is unclear whether it actually is supported or not. Also, iirc TME is only available on vPro CPUs (I could be wrong on this though). The CPUs they offer are “eligible” for vPro, but they don’t advertise it on their website, so I am not sure if they even support vPro features and especially TME or not.
You flash the ROM using the internal programmer, either you download their ROM or you compile it yourself, you can flash from a Linux livecd or use their update suite. If you have a paid subscription you can PXE with a Linux from the boot menu and update from internet.
This does not sound right. I should not be able to just compile arbitrary code and flash it. If this is possible, it probably means that Intel BootGuard isn’t actually set up, and it makes the whole boot security useless because an attacker can just flash malicious boot firmware and subvert everything down in the boot chain. Coreboot + Tianocore only means something if the CPU verifies their authenticity/integrity.
I’m pretty sure the CPUs are vPro, they are just not enterprise eligible, which means they don’t have AMT. Don’t know if you can use TME with vPro essential, but I believe you can.
Yes, you should be able to compile your own code and flash the firmware yourself, it’s the entire point of using Coreboot. This obviously doesn’t work if the system is locked with Intel BootGuard, but you can buy a locked system with closed source firmware if you believe that is more safe.
No, this is absolutely not how it works. “Close sourced” is not what matters here. This is also not what Coreboot is about.
A proper boot chain goes as follows:
Intel ME (uses BootGuard with the OEM’s key and verifies the boot firmware) → The firmware signed with the OEM’s key (uses UEFI secureboot dbx to verify the next boot stage - this is where you do custom key enrollment) → Next boot stage (be it a UKI, Shim, or whatever).
The reason why Google’s system actually means something because they have a root of trust. With vboot, it is the readonly region on the SPI flash. This is mentioned right in the link you sent:
When using vboot, the root-of-trust is basically the read-only portion of the SPI flash.
The firmware is typically protected using the write-protect pin on the SPI flash part and setting some of the write-protect bits in the status register during manufacturing. The protected area is platform specific and for x86 platforms is typically 1/4th of the SPI flash part size. Because this portion of the SPI flash is hardware write protected, it is not possible to update this portion of the SPI flash in the field, without altering the system to eliminate the ground connection to the SPI flash write-protect pin. Without hardware modifications, this portion of the SPI flash maintains the manufactured state during the system’s lifetime.
In the typical boot chain I described, the boot guard key inside of the ME is the root of trust. Without BootGuard, everything down the chain is security threatre.
There is nothing stopping Coreboot from being used with BootGuard. What matters here is that the OEM enroll their own key into BootGuard, then distribute a signed copy of their firmware. That firmware can be Coreboot + Tianocore if they want it to be so. An OEM not setting up BootGuard and not signing their firmware would be a problem. Again, this has nothing to do with whether something is closed source or open source - it has everything to do with having a root of trust.
This is also why the devices which can have Coreboot flashed after the fact, including the bunch of ThinkPad X2xx and T4xx that got the Qubes certification, are inherently insecure and cannot be trusted.
I don’t know how to explain it to you, but if you want Intel BootGuard you shouldn’t buy a system with Coreboot. Some companies sell the same models with or without Coreboot, if you want BootGuard pick the version without Coreboot.
Some people specifically want the option to compile and audit the firmware, you get that option with Coreboot because it’s open source.
I understand that there are very few if any systems with BootGuard + Coreboot properly setup. There is nothing technical that prevents them from working with each other. There is nothing stopping a vendor from signing Coreboot with their own key. Just because something is signed doesn’t mean it can’t be audited.
Some people specifically want the option to compile and audit the firmware, you get that option with Coreboot because it’s open source.
That doesn’t mean anything. What is the threat model? Is it to protect from evil maid attacks? Because if it is - this is completely useless. An attacker can just compile their own malicious firmware and flash it straight onto the computer. What’s stopping them?
I cannot talk about the in-laptop CPUs discussed here, but I got a regular i9 and TME works there with the dasharo coreboot by default (on msi z690a). I tested out the hard way - had some a bit flaky ram and when running memtest - single bit errors manifested themselves are a total garbage on dasharo, as single bit errors on stock firmware. So if Dasharo says it works - it does. There’s a bit of memory access penalty too.
I would not say it is “completely useless”. Unless you are Intel - you cannot just compile your own Intel ME firmware. So various tricks that AEM plays are much better than nothing, the whole writing system state into PCRs and then if the PCRs don’t match expected values, then the displayed secret is wrong and when it happens - you don’t enter your decryption password and the attack fails.
I don’t think you can update the vboot keys using the internal programmer, I believe it would stop anyone that doesn’t have access to the system and is able to flash the ROM with an external eprom programmer.
I am not entirely sure I follow. I don’t see how the ME has anything to do with this either.
According to the README, the BIOS must truly be trusted. And it makes sense. The problem here is that there is no BootGuard, so nothing verifies if the BIOS has been tampered with or not. Any attacker can just flash whatever they want onto the BIOS chip. How is the entire system not completely useless at this point?
But then that is the point - if the threat model is an evil maid attack, you gotta assume that they have access to the system and is able to use an external programmer. What is even the point if you cannot defend against that?
ME is what provides you various TPM/SGX functionalities that AEM depends on.
It has those “read only”/“write once” PCR values that the untrusted code cannot change.
I think you misunderstood the bios comment in the readme. All it says is that there are bios bugs that can affect functionality (around SMM areas).
If your threat model includes “attacker can sign ME image with a valid Intel key” then yes, AEM is not effective.
If you need to worry about secret agents reprogramming your laptops with an external programmer, then seal the case preventing non-destructive opening, or buy the model from Nitrokey with heads.