
PureBoot, the High Security Boot Process - kgwxd
https://puri.sm/posts/pureboot-the-high-security-boot-process/
======
elagost
It's great that they're putting so much care and attention something that's
usually overlooked - motherboards/laptops are released and often shortly
abandoned by manufacturers if they're not flagship models, leading to security
holes, missing features, or poor performance.

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.)

~~~
ac29
> 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](https://support.lenovo.com/us/en/downloads/ds029187)

[1]
[https://support.lenovo.com/us/en/downloads/ds029252](https://support.lenovo.com/us/en/downloads/ds029252)

~~~
joewee
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](https://github.com/Cr4sh/ThinkPwn)

You can’t trust thinkpads for security.

~~~
mehrdadn
You sure? I don't see the T470+ series on the vulnerability list:
[https://support.lenovo.com/us/en/solutions/len-8324](https://support.lenovo.com/us/en/solutions/len-8324)

~~~
joewee
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](https://github.com/chipsec/chipsec)

~~~
bubblethink
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.

~~~
joewee
Ok. Thanks. I haven’t actually tried to run the PoC against it.

------
pizzazzaro
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?

~~~
pa7ch
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.

~~~
AlexCoventry
Is there a better Linux option than crouton?

~~~
jasonvorhe
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.

------
Boulth
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.

~~~
techntoke
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.

~~~
tejado
+1, please share your setup

~~~
Boulth
Sorry for the late reply but check out [https://github.com/electrickite/luks-
tpm2](https://github.com/electrickite/luks-tpm2) and scencrypt in AUR.

~~~
techntoke
That is freaking cool. Thanks!

------
bri3d
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](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).

~~~
derefr
> 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"?

~~~
bri3d
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."

------
mr_puzzled
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.

~~~
codemusings
> \- 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](https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf)
[2] [https://puri.sm/posts/deep-dive-into-intel-me-
disablement/](https://puri.sm/posts/deep-dive-into-intel-me-disablement/)

~~~
pjc50
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.

~~~
markjenkinswpg
A perfect example of getting lucky. How long until subsequent Intel releases
lack this.

------
ncmncm
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.

