PureBoot, the High Security Boot Process(puri.sm)
puri.sm
PureBoot, the High Security Boot Process
https://puri.sm/posts/pureboot-the-high-security-boot-process/
42 comments
> Seems like similar-year Thinkpads have been abandoned for 4 or 5 years now.
Hmm? The X230 and T430 (Ivy Bridge era Thinkpads) both had BIOS updates in the past 6 months [0][1]. Lenovo is far from perfect as a vendor, but they are good about firmware updates for Thinkpads.
[0] https://support.lenovo.com/us/en/downloads/ds029187
[1] https://support.lenovo.com/us/en/downloads/ds029252
Hmm? The X230 and T430 (Ivy Bridge era Thinkpads) both had BIOS updates in the past 6 months [0][1]. Lenovo is far from perfect as a vendor, but they are good about firmware updates for Thinkpads.
[0] https://support.lenovo.com/us/en/downloads/ds029187
[1] https://support.lenovo.com/us/en/downloads/ds029252
What is amazing is that despite updates, Lenovo still hasn’t fixed the gaping security flaw affecting almost all Thinkpads.
https://github.com/Cr4sh/ThinkPwn
You can’t trust thinkpads for security.
https://github.com/Cr4sh/ThinkPwn
You can’t trust thinkpads for security.
You sure? I don't see the T470+ series on the vulnerability list: https://support.lenovo.com/us/en/solutions/len-8324
That list hasn’t been updated since 2016, but they continue to ship vulnerable firmware. Including in all bios updates since 2016.
You would have to dump an image of your bios firmware using chipsec to confirm for yourself. https://github.com/chipsec/chipsec
You would have to dump an image of your bios firmware using chipsec to confirm for yourself. https://github.com/chipsec/chipsec
They did patch the reported vulnerabilities in updates. What chipsec reports as warnings are not necessarily exploitable. i.e., They didn't patch them to the extent of getting all green ticks in chipsec, but it does not automatically imply exploitable.
Ok. Thanks. I haven’t actually tried to run the PoC against it.
Interesting. Since I last checked, my X220 hadn't received any updates in more than a year, and I run coreboot now, so I've stopped checking. Looking now, it seems they released one in January. Seems like my impressions were wrong.
I dont know about anyone else, but Im a little scared by the fact that I've never owned a coreboot-compatible device. Look around on their website, and you may notice that the compatible hardware selection is rather... limiting.
Oh, dont get me wrong. I've flashed the old skylake SOC with a HAP-mode / ME-cleaner variant. But I dont consider that very helpful when compared to an audit-able boot process.
How do I go about fixing this? I want coreboot, how do I get in and get it?
Oh, dont get me wrong. I've flashed the old skylake SOC with a HAP-mode / ME-cleaner variant. But I dont consider that very helpful when compared to an audit-able boot process.
How do I go about fixing this? I want coreboot, how do I get in and get it?
Maybe not the answer your looking for but any Chromebook has a fork of coreboot that I think follows upstream closely.
Chromebooks have been far ahead for awhile in boot security and chromeOS is becoming quite usable with its Linux container support.
Chromebooks have been far ahead for awhile in boot security and chromeOS is becoming quite usable with its Linux container support.
Is there a better Linux option than crouton?
Yes, Crostini is awesome since it doesn't compromise on security and still offers close to native performance.
Integration into Chrome OS is ongoing though. Some features like graphics acceleration and sound are still incomplete.
Integration into Chrome OS is ongoing though. Some features like graphics acceleration and sound are still incomplete.
I cannot vouch for "better" but there's also croustini.
Thinkpad
The thing is it doesn't matter that much anymore, so people aren't working on it. Both AMD and Intel modern CPUs require proprietary embedded firmwares to even get to the boot stage (as you know).
And logically it makes sense - there is no real distinction between hardware and software - it should be an implementation detail.
And logically it makes sense - there is no real distinction between hardware and software - it should be an implementation detail.
I must say I am impressed by their level of professionalism and I did setup my own GPG decrypted (with Yubikey) and TPM decrypted LUKS scripts on Arch.
Very cool. Can you please help add any information to the Arch Wiki about your setup and methods? The information surrounding TPM 2.0 and Secure Boot is lacking, but an area that I hope will be greatly improved an automated.
Here's a 2017 article on Fedora setup with TPM2, https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-...
+1, please share your setup
Sorry for the late reply but check out https://github.com/electrickite/luks-tpm2 and scencrypt in AUR.
That is freaking cool. Thanks!
No problem.
If I may suggest something if you have TPM version 2 use sha256 everywhere. And you can expand the PCRs list to cover more stuff. I'm using PCRs 0 to 8 (or 9? Can't check now) so any hardware configuration change is apparent during boot.
Another useful package is sbupdate [0] that not only signs kernel for SecureBoot but additionally makes it possible to boot the kernel directly from UEFI firmware bypassing the need for bootloader (be it grub or systemd boot). Once setup it just works!
[0]: https://github.com/andreyv/sbupdate
If I may suggest something if you have TPM version 2 use sha256 everywhere. And you can expand the PCRs list to cover more stuff. I'm using PCRs 0 to 8 (or 9? Can't check now) so any hardware configuration change is apparent during boot.
Another useful package is sbupdate [0] that not only signs kernel for SecureBoot but additionally makes it possible to boot the kernel directly from UEFI firmware bypassing the need for bootloader (be it grub or systemd boot). Once setup it just works!
[0]: https://github.com/andreyv/sbupdate
My knee-jerk reaction to this project is that it would be overall inferior to simply allowing coreboot to measure and boot the user's desired Linux distribution directly, and vastly inferior to a small first-stage bootloader written in a safer language than C. I still think that's mostly true - at the end of the day, you're introducing a second Linux distribution to maintain and audit into your bootchain. However, the 33c3 presentation about Heads at least presents a few decent arguments for using Linux : https://trmm.net/Heads_33c3#Philosophy_of_Heads .
Fundamentally I'm not sure I agree with the concept that Linux could be more robust, secure, audited, or hardened than an open-source miniaturized early stage bootloader audited by a good security research firm. I think the dated "more eyes makes more more secure software" concept has been fairly debunked at this stage and the path towards security will revolve around smaller trusted components written in a memory-safe language (i.e. not C).
Fundamentally I'm not sure I agree with the concept that Linux could be more robust, secure, audited, or hardened than an open-source miniaturized early stage bootloader audited by a good security research firm. I think the dated "more eyes makes more more secure software" concept has been fairly debunked at this stage and the path towards security will revolve around smaller trusted components written in a memory-safe language (i.e. not C).
> a small first-stage bootloader written in a safer language than C
Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C?
> written in a memory-safe language
What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?
Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C?
> written in a memory-safe language
What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?
Certainly escaping the hell that x86 puts you in early in the boot process requires a bit of assembler, yes.
I think we're mostly talking past one another semantically if you believe that "most of what a bootloader does is calling arch-specific opcodes."
Most projects I'm familiar with called "bootloader" (including coreboot, GRUB/LILO, etc.) are by and large, both by lines of code and complexity, focused on loading binary files from disk using a filesystem driver, parsing them (!!!), and then passing off execution - all tasks which are better handled by a language or framework where it's not so easy to make a parsing mistake which compromises an entire system. This is true especially once trust chain verification and cryptography are also thrown into the mix.
Now that you've gotten me thinking about it as well, static verification of the real mode portion of a bootloader should be entirely possible. Although I'm not sure of a good toolset for doing so off the top of my head, there's nothing theoretically stopping someone from implementing a safe(ish) system which is capable of assembling software which could operate in real mode.
Anyway, since it seems unclear: my main thesis is "introducing Linux to the trust verification part of your boot process seems rather ridiculous because it is a gigantic surface area implemented in a way that makes it exceptionally challenging to audit."
I think we're mostly talking past one another semantically if you believe that "most of what a bootloader does is calling arch-specific opcodes."
Most projects I'm familiar with called "bootloader" (including coreboot, GRUB/LILO, etc.) are by and large, both by lines of code and complexity, focused on loading binary files from disk using a filesystem driver, parsing them (!!!), and then passing off execution - all tasks which are better handled by a language or framework where it's not so easy to make a parsing mistake which compromises an entire system. This is true especially once trust chain verification and cryptography are also thrown into the mix.
Now that you've gotten me thinking about it as well, static verification of the real mode portion of a bootloader should be entirely possible. Although I'm not sure of a good toolset for doing so off the top of my head, there's nothing theoretically stopping someone from implementing a safe(ish) system which is capable of assembling software which could operate in real mode.
Anyway, since it seems unclear: my main thesis is "introducing Linux to the trust verification part of your boot process seems rather ridiculous because it is a gigantic surface area implemented in a way that makes it exceptionally challenging to audit."
every compiled code is assembly. C was considered very high level, at some point in history.
> What does this even mean in bootloader land
that your disk encryption password input can't override the program data that will later on write to some bios memory address, for example. who knows? If I knew they wouldn't be undiscovered bugs, but CVEs :)
> What does this even mean in bootloader land
that your disk encryption password input can't override the program data that will later on write to some bios memory address, for example. who knows? If I knew they wouldn't be undiscovered bugs, but CVEs :)
A lot depends on where "first stage" actually is, but if we look at grub for example: https://github.com/coreos/grub/tree/2.02-coreos/grub-core/bo...
The assembler isn't interleaved with C, it runs first; once the setup is complete, control is transferred to C. I think this is the pattern that should be followed as much as possible: small platform-specific bits, then switch to higher-level language runtime. Certainly as soon as you're parsing input or doing cryptography a high level language becomes an advantage (with the requirement to call back to low-level occasionally). Rust seems to be the closest match here.
The assembler isn't interleaved with C, it runs first; once the setup is complete, control is transferred to C. I think this is the pattern that should be followed as much as possible: small platform-specific bits, then switch to higher-level language runtime. Certainly as soon as you're parsing input or doing cryptography a high level language becomes an advantage (with the requirement to call back to low-level occasionally). Rust seems to be the closest match here.
The other downside I see is that it rules out booting other operating systems (at least right now). Other than linux itself (and maybe freebsd?) you can't kexec from a running linux kernel to another OS.
Not sure if this is current, but apparently you can kexec to grub4dos, an on to windows (i assume this won't work for W10 with secure boot enabled, though):
http://reboot.pro/topic/7223-how-to-boot-directly-into-windo...
http://reboot.pro/topic/7223-how-to-boot-directly-into-windo...
You actually can.
How does one boot windows from a running linux kernel ?
I don't know the details but I recall that using linux as a bootloader was a potential threat the ChromeOS people wanted to block with some patches to the Linux kernel that tied it somehow to secure boot that the kernel maintainers (Linus himself commented on the issue as it was controversial) rejected at the form the patches had at the time.
Here's a post, with some technical details, from one of the developers that were involved in the issue: https://mjg59.dreamwidth.org/50577.html
Here's a post, with some technical details, from one of the developers that were involved in the issue: https://mjg59.dreamwidth.org/50577.html
I think there are two things being conflated here:
- the "shim" bootloader: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloa... - it's important that this can't be used to boot a Windows that thinks it's secure but isn't.
- the "lockdown" patches you refer to. The goal of those is to maintain the attestation that the running kernel code is the code that was loaded through a signature chain. If you can modify the kernel at runtime, obviously the attestation has to be invalid.
I don't think it's impossible to boot Windows from Linux, but doing so should result in Windows detecting that it's in insecure/unsigned mode.
- the "shim" bootloader: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloa... - it's important that this can't be used to boot a Windows that thinks it's secure but isn't.
- the "lockdown" patches you refer to. The goal of those is to maintain the attestation that the running kernel code is the code that was loaded through a signature chain. If you can modify the kernel at runtime, obviously the attestation has to be invalid.
I don't think it's impossible to boot Windows from Linux, but doing so should result in Windows detecting that it's in insecure/unsigned mode.
But why couldn't you?
You may be interested in TrenchBoot, https://github.com/TrenchBoot/documentation/blob/master/docu...
First off, I'm rooting for Purism since they focus on hardware for running linux distros. But, what concerns me is that they don't seem to acknowledge that parts of the system contain proprietary software.
- Coreboot iirc requires binary blobs. Libreboot is truly FOSS, but only works on ancient cpus
- ME can't actually be disabled completely according to Qubes OS founder Joanna.
I think it's crucial to also talk about the limitations of the system.
- Coreboot iirc requires binary blobs. Libreboot is truly FOSS, but only works on ancient cpus
- ME can't actually be disabled completely according to Qubes OS founder Joanna.
I think it's crucial to also talk about the limitations of the system.
> - ME can't actually be disabled completely according to Qubes OS founder Joanna.
In case you're referring to her article titled "Intel x86 considered harmful"[1] it's worth noting that she only speculated the following:
> A large part of the ME firmware is stored on an SPI flash chip, which admittedly could be reprogrammed using a standard EEPROM programming device to wipe all the ME partition from the flash. But this approach does not have a good chance of succeeding. This is because the processor itself contains an internal boot ROM [37] which is tasked with loading and verifying the rest of the ME code. In case the bootloader is not able to find or verify the signature on the ME firmware, the platform will shutdown.
However, if I understand correctly, that's exactly what Youness Alaoui[1] at Purism did.
[1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf [2] https://puri.sm/posts/deep-dive-into-intel-me-disablement/
In case you're referring to her article titled "Intel x86 considered harmful"[1] it's worth noting that she only speculated the following:
> A large part of the ME firmware is stored on an SPI flash chip, which admittedly could be reprogrammed using a standard EEPROM programming device to wipe all the ME partition from the flash. But this approach does not have a good chance of succeeding. This is because the processor itself contains an internal boot ROM [37] which is tasked with loading and verifying the rest of the ME code. In case the bootloader is not able to find or verify the signature on the ME firmware, the platform will shutdown.
However, if I understand correctly, that's exactly what Youness Alaoui[1] at Purism did.
[1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf [2] https://puri.sm/posts/deep-dive-into-intel-me-disablement/
By my reading of this, it's hilarious: they turned on a feature that was provided for the NSA, the "HAP" bit. This put the ME into a special high assurance mode. But because it can't find the rest of the HAP software, it goes into "disabled" mode - without disabling the rest of the platform.
A perfect example of getting lucky. How long until subsequent Intel releases lack this.
> But, what concerns me is that they don't seem to acknowledge that parts of the system contain proprietary software.
They do acknowledge it:
https://puri.sm/learn/software-freedom-in-perspective/
https://puri.sm/learn/freedom-roadmap/
They do acknowledge it:
https://puri.sm/learn/software-freedom-in-perspective/
https://puri.sm/learn/freedom-roadmap/
Previously I have been put off by the greater expense of specialty solutions, vs mass market products: generally, because despite the higher prices, the gains were illusory. A bit of tweaking gave the same (limited!) degree of security on stock hardware.
Purism is unique in their defense-in-depth approach. They earn every penny of the higher price, and the price is remarkably little higher. I ordered a Librem 5 phone last year, for more than I had ever paid for a phone, and don't mind waiting while they get it right.
The spook agencies should be their biggest customers -- alongside every legislative staff office and flagship-newspaper office.
Purism is unique in their defense-in-depth approach. They earn every penny of the higher price, and the price is remarkably little higher. I ordered a Librem 5 phone last year, for more than I had ever paid for a phone, and don't mind waiting while they get it right.
The spook agencies should be their biggest customers -- alongside every legislative staff office and flagship-newspaper office.
Is there any way to tell, prior to purchase, if a system is going to have good support? I have a Dell Latitude from 2012 (Ivy Bridge CPU) and it's still getting BIOS updates, which is great. Seems like similar-year Thinkpads have been abandoned for 4 or 5 years now.
(edit: this is incorrect, thanks ac29. Bad comparison. The complaint still stands; many devices are released that see two or less updates, but they tend to be consumer-facing, not business-oriented, like Dell's Latitude line or Lenovo's Thinkpad line.)