PureBoot, the High Security Boot Process
puri.sm
puri.sm
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.)
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.
https://github.com/Cr4sh/ThinkPwn
You can’t trust thinkpads for security.
You would have to dump an image of your bios firmware using chipsec to confirm for yourself. https://github.com/chipsec/chipsec
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?
Chromebooks have been far ahead for awhile in boot security and chromeOS is becoming quite usable with its Linux container support.
Integration into Chrome OS is ongoing though. Some features like graphics acceleration and sound are still incomplete.
And logically it makes sense - there is no real distinction between hardware and software - it should be an implementation detail.
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).
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
- 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.
http://reboot.pro/topic/7223-how-to-boot-directly-into-windo...
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"?
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."
> 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 :)
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.
- 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.
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/
They do acknowledge it:
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.