Bootstraping a slightly more secure laptop (33c3)

33c3 preroll music

Herald: So, the last speaker for this
morning is Trammell. He is doing

awesome research on "Bootstrapping
more secure laptops or servers" and

he is doing that basically by moving the
root of trust into the write-protected room.

He is building an open-source custom
firmware, so big ups for that, and also

encouraging the research on this field
which I believe it's super interesting.

Thanks!
applause

applause

Trammel Hudson: So I'm Trammell Hudson
with Two Sigma Investments, and for the

past several years I've been researching
firmware security vulnerabilities

and looked at how they affect systems.
Two years ago, I presented my work

on Thunderstrike here at CCC. And this was
the first firmware attack against MacBooks

that allowed an attacker to override
the motherboard bootrom.

The year after that, I collaborated with
Xeno Kovah and Corey Kallenberg

from LegbaCore - both of whom
are now at Apple, doing firmware work.

And we ported a bunch of Windows UEFI
vulnerabilities over to the Mac, and

showed that the software platform - the
UEFI software platform, you know - allowed

very portable attacks to be done. This
also allowed a remote attacker with code

execution on your machine to override the
motherboard bootrom. But, more than just

breaking things, what we like to do is
take the things apart and understand how

they work and document them, so that other
people can build systems on top of them.

And that's why I'm really excited to be
talking to you all about my project

"Heads", which is a open source
firmware and boot loader

for laptops and servers.
The name is kind of a play

on the popular 'Tails' distribution
which is a stateless Linux

for when you don't want to leave any traces
of what you're doing on your machine.

Heads is for the opposite case: it's where
you want to be able to trust the machine,

and you want to be able to trust that the
data you store on the machine is safe

and unmodified. And, let's back up
for a quick minute and just talk about

why firmware security is so important,
that this is the code that is

executed by the CPU when it comes out of
reset. This is the first instruction that

the CPU executes. And so it's in a really
privileged position to be able to

circumvent any sort of OS or other
policies. And there's no shortage of talks

that you can watch on interesting
attack vectors using firmware-based

malware. One that I really liked
was last year at DEFCON. The

Intel Advanced Threat Research
presented an attack that showed

how firmware could - malicious firmware -
could circumvent the hypervisors. They

then went further and showed how buggy
firmware allowed a unprivileged guest

inside a virtual machine to escalate into
privileges inside the hypervisor. And for

that reason, it's really important that
firmware vulnerabilities and firmware bugs

have a way to get patched. These aren't
just theoretical research vulnerabilities,

either. We know that there are malicious
organizations and hacking groups that are

selling firmware rootkits to whoever will
pay - including nation-state adversaries,

that are using them for their persistent
threats. And they are very persistent,

because they are in the motherboard
bootrom So you've reinstalled the OS -

they're still there, you swap out the hard
drive - they're still there. And some

vendors are even bundling these rootkits
into their official ROMs. That they are

using them to install the bloatware, or
whatever adware they want to put into the

OS. So even after you reinstall a clean
version of the OS, this particular vendors

system would install its own additions.
Some of those had vulnerabilities that

could then be exploited by attackers. This
particular case, the vendor received

enough bad press, that they released a
firmware update that patched this

vulnerability. And they had to do that.
This wasn't something that the users could

do on their own - they couldn't update the
the firmware in their machine the

way they do with their operating system or
an application. And in fact, most firmware

vulnerabilities never see patches get
deployed out to the end-user.

Part of the reason for that is that the
the firmware is usually four or five

companies, removed from the end-user. That
there's the open source reference

implementation from Intel, called eh
TianoCore or EDK II. When vulnerabilities

are patched in there, they have to get
pulled by the independent BIOS vendor, and

merged into the IBV tree, and then the
BIOS vendor sells that to the device

manufacturers. So they have to package up
a release the thing gets pulled by the

device manufacturer. It has to get QA'd it
against however many motherboards they

want to test it on. And then it has to get
again pulled by the original equipment

manufacturer to get rebranded and whatever
value they want to add. And then sometimes

it has to go through the operating system
vendor to even make it out to the end-

user. And as a result of this, most of the
time, products do not receive any updates

after they've been sold. There's one
exception: in this chart you can see that

Apple builds their own firmware, and in my
work with them, I've been really pleased

that they've rolled out patches for eight
years of hardware. Which is above and

beyond what any other firmware vendor is
doing right now. When EFI was introduced,

it brought a lot of complexity, and the
Linux community was very skeptical as to

what the value was going to be provided by
all this complexity. It's basically an

entire operating systems worth of code.
And it's not, that the 16-bit real-mode

BIOS was all that much better. In fact, it
had its own set of issues. But it was

small, it was simple, it did one thing, it
did it okay. And it took a long time for

UEFI to even become widely supported. But
even now most systems ship with both the

UEFI and a BIOS compatibility module. So
they've basically doubled their attack

surface for potential bugs and
vulnerabilities. So the state of the

firmware world today is that updates are
rare, patches, if they ever come out, take

a long time to make it through the
process.

Users can't fix things on their own, and
we can't see what's inside, since most of

them are built with closed source
components - and that's not a great state

for something that is as privileged as a
firmware. So it's my belief, that firmware

needs to be built with open source. It
must be flexible, so we can adapt it to

our needs for our systems. It needs to be
built with software that we understand and

we use for, in, other applications, so
that it can get widely tested and well

tested. It needs to be built in a
reproducible manner, so that we can be

secure against that build chain attacks.
And it needs to be cryptographically

measured, so that we can be sure that
this, what we flash on the system, is what

is actually running on the system. And
that's the philosophy behind Heads - it's

built on the free software coreboot
firmware, plus a Linux kernel in ROM, that

acts as a bootloader, and then a lot of
security research and tools, that help us

try to build slightly more secure systems.
Using Linux as a bootloader is not a

particularly new idea. Back in the 1990s
when we started building large scale Linux

clusters, we were very frustrated with the
inflexibility of DHCP and PXE booting

large machines, that even with those
frustrations, we built one, that was about

the 30th fastest in the world on the top
500. Meanwhile, my colleague Ron Minich at

Los Alamos was also building large
clusters, and had the observation that the

BIOS enumerates all the buses, initializes
a bunch of devices, finds the Linux kernel

and in the Linux kernel, enumerates all
the buses, initializes all the devices,

and he thought: "This is this is silly,
why are we doing this twice?".

So he had the idea to build a version of
Linux, that ran in the ROM. He called this

project "Linux BIOS" and it went on to
power the MRC cluster, which was the third

fastest machine in the world in 2003. In
2008 Linux BIOS underwent a major

refactoring and it was renamed to
"Coreboot". And Google chose to use

Coreboot as the firmware on their
Chromebooks - which are at this point the

only non-UEFI x86-based laptops that you
can buy. And they've done some really some

great work in trying to lock down the
configuration and the firmware on the

Chromebooks. Ron, who has only moved to
Google in 2011 and is continuing to work

on the Coreboot project there. So Coreboot
has three stages that it goes through as

it starts up the machine: the first one is
a very small amount of real-mode assembly,

because your modern 64-bit laptop still
boots up in real mode with 16-bit just

like its 1970's. So that's a very small
amount of code - about 1.5K. That in turn

sets up a C runtime environment with
what's called "Cache-as-RAM mode" and it

calls into the ROM stage which is about
70K. "Heads" has moved the TPM

initialization early in the ROM stage
before DRAM is set up to help measure the

boot block and provide a static route of
trust that's hopefully a little bit more

secure. And because that measurement is
done early on, our trusted computing base

is actually quite small. This is a
fraction of 1% of the size of a UEFI

firmware, which is usually about 16 MB
once it's uncompressed.

The ROM stage then measures and executes
the RAM stage, which does the more

traditional "walk the bus, find / figure
out what devices are on there", but it

doesn't initialize them: it just
enumerates them and generates the

descriptors for Linux. It also installs
the SMM handler for system management

mode. It then measures and jumps into the
payload - and that whole process takes

less than a second. So it is able to get
into the payload and actually get to the

user code very, very quickly. On something
like the X230 it's able to go from power

on to a interactive recovery shell in less
than 2 seconds. And that includes bring up

the TPM, doing cryptographic measurements
and assessing the state of the system.

Because we now have Linux at this point,
we have all the flexibility that comes

with that. We can implement boot scripts
with the full power of the shell or the C

language runtime:
we're not stuck with the limited functions

of UEFI. Linux supports lots of different
file systems. It supports lots of

different devices. It supports lots of
different encryption methods. And this

gives us the ability to use any of them
for your specific application. In

contrast, UEFI, which supports unencrypted
FAT file systems on the first drive that

have to be in the first 1 GiB or
something, it's really, really limited as

to how it can find its boot device.
There's a saying in the in the Open Source

community that with enough eyes all bugs
are shallow.

And Linux has a lot more eyes looking at
it. That the device drivers and the file

systems and the encryption have been
reviewed by both white hat and black hat

people around the world. The UEFI versions
of these do not have that same level of

scrutiny, so we're using both the UEFI
drivers and then having to run whatever on

top of it, increases the attack surface.
But by putting Linux in the ROM and

depending on its drivers we've reduced our
attack surface very dramatically. More

importantly though, Coreboot and Linux are
Open Source, so it is possible to build

custom versions for the device drivers
that you need, for the file systems that

you need. It's possible to fix bugs when
they come out, and sign and install your

own kernels. You don't have to wait for
the vendor to get around to doing it.

And the third major component of heads is
a tool called "kexec", which is a system

call that was added for the Linux BIOS
project back in 2003 by Eric Peterman,

that allows a running kernel to do a
graceful shutdown and start a new kernel

without having to go through the reboot
process. So this allowed, on their

application, it allowed them to do very
fast reboots of their cluster nodes. And

in the "Heads" case, it allows us to act
as a bootloader where we can find the real

kernel, that you want to run, and exec it.
Because "Heads" is quite small. It has to

fit in 4 MB of ROM. So it's not something
that you learn to run as a day-to-day sort

of OS. Hopefully this won't explode on me
again.

Because we have the Bourne Shell, most of
the policies and the startup scripts in

"Heads" are implemented as as shell
scripts. In this case we were able to pass

in a new set of command line parameters, a
new initial RAM disk, and in this case we

can even start a hypervisor. And all of
that can happen very very quickly, as well

as with with a good degree of security.
So, those are the building blocks that

"Heads" is built on: Coreboot, Linux and
tools like "kexec". But it now gives us a

really nice platform to begin
experimenting with additional security

features. And before we go too deep down
the rabbit hole of, you know, security and

threat models, I want to quote my friend
Steph, who said that, "Your threat model

is not my threat model."
But you know your threat model is okay as

well, that we all have different things we
want to protect, from different attackers,

who are willing to spend different amounts
of effort to go after them. And the nice

thing about having an open source is: We
can build systems tailored to your

individual threat model. So a lot of these
things may not actually apply to your

specific threats, but the fact that we can
build them is a great capability. Last

year Joanna Rutkowska reminded us that
firmware is not just in our CPU. Firmware

is in our Wi-Fi card. It is in our GPU. It
is in our SSD. It is in our keyboards. And

all of these devices might be trying to
subvert the boot process.

One way to handle that is to take Peter
Stuge's advice of disassembling the

machine and ripping out anything we can't
control. If this is your threat model, his

instructions are really worth following.
They're really thorough about what pieces

are potentially of concern. And you're
going, right now, you'll have to open up

your laptop to install "Heads." It's not
quite as easy as it is to install most

Linux distributions, because we have to
flash it into the motherboard boot ROM.

While we're in there, now, we take
advantage of some features that, to the

best of my knowledge, no UEFI system is
using. These flash chips have a hardware

write-protect mode, where you can specify
part of the chip is write-only. Excuse me.

Is read-only, write-once. And this gives
us our immutable boot block in which to

store the trusted computing base, the TCB,
so that we can measure the rest of the

system. We also then suggest disconnecting
the write-protect PIN from the

motherboard, which protects against
certain classes of attacks, like the Intel

close chassis adapter, that allows
external JTAG of the CPU.

Depending on your threat model you might
want to cover that chip in epoxy as well,

to frustrate Evil Maid attacks that want
to do a physical programming on it.

Disconnecting the write-protect PIN also
serves to protect from other devices on

the machine that have access to those
PINs. Devices like the Management Engine,

which is a really scary CPU inside the
CPU. Rudolf Marek two years ago at CCC

called it the "Matroyshka CPU".
And Igor Skochinsky detailed what are the

capabilities of the management engine. And
they're really worrisome, that it runs a

opaque obfuscated blob of code about 5 MiB
that the CPU can't see. The management

engine can read and write all of main
memory. It can read from the keyboard and

video. It can receive Java bytecodes over
the network and execute them on behalf of

someone outside the machine. And it's
listening on the network even when the

system is powered off.
So this is basically a rootkit inside the

chipset, as some folks have called it. So
that concerned me a lot, and I spent some

time looking at how its firmware images
are built, and realized that we can build

modified, reduced functionality firmware
for it that removes all of the rootkit

functions, and just leaves the "CPU bring
up" module. This takes that 5 MiB and

shrinks it down to about about 40 KiB of
space. So we don't know exactly what it's

doing in that 40 KiB, but we at least know
it doesn't have a device driver, or a Java

Virtual Machine, or a lot of the other
functions.

And we've successfully done this on both
Sandy Bridge and Ivy Bridge like the X230

ThinkPads as well as modern Skylake CPUs
like the Chell Chromebook. And that's

really encouraging, that if we can apply
this to more modern hardware, that allows

us to, you know, move away from our five-
year-old ThinkPads to something a little

shinier. The management engine isn't the
only device that might be trying subvert

the boot process. Again Johanna showed us
there are lots of things to be worried

about. Intel's UEFI architects, Yao and
Zimmer, recommend that firmware turn on

the IOMMU, now called VTD, to protect
against rogue devices. To the best of my

knowledge, since they've written this
guide, no UEFI firmware is taking

advantage of the IOMMU. So, it's a great
piece of hardware to have, but it doesn't

help if you don't turn it on. Linux,
meanwhile has no problem taking advantage

of it, so we use it, what we get
essentially - we get that DMA protection

for free by using Linux as our bootloader
in the ROM. Another way devices, rogue

devices, can try to interfere with the
boot process is by providing option ROMs,

which are executable code to be run by the
BIOS, that have a sort of a device driver.

And this code can do things like about log
keystrokes and then try to exfiltrate

passwords as we see here. That problem was
initially reported in 2007 by John Heasman

at BlackHat, again by Snare in 2012, and
again by my work on Thunderstrike. And as

of last week a official fix has finally
rolled out for it to close that particular

vulnerability.
Folks who are using coreboot have this as

a option that they can say, this, I am
concerned about this threat, let me let me

fix this, let me disable this function.
And they point out that it might cause

degraded functionality, but that's
something you can QA on your own system.

And in practice with Linux as your
bootloader in the ROM, you don't use the

option ROMs for anything. Everything is
done with with Linux's own device drivers,

so you're not dependent on the whatever
limited functionality the option ROM

provided.
So, now that we have we've taken our

building blocks and we hopefully have
protected the boot process, and hopefully

the code that's running is what we think
it is, we need to turn to how do we secure

the secrets on the machine. And I'm a huge
fan of the TPM, the Trusted Platform

Module, now I know in the free software
community it's been largely unwelcome. It

has not received a very welcome reception,
because of the way it's been used for DRM

and other other user-hostile things. Since
we control the TPM from the first

instruction in the in the boot block,
we're able to use it in ways that we want

to, so we don't have to enable DRM, but we
can use it to protect our secrets. And the

the way that it does that, is it keeps
track of what code is executed as the

system boots, and it hashes that code into
special registers called PCRs. And the

idea is that, you can extend the PCR by
hashing the next module of code, and then

hashing that with the previous hash, and
this creates a chain of trust that allows

to say: If these hashes match the expected
values, only the code, that we want to

have run, has run. And then the TPM will
only decrypt the the disk encryption key

if those PCRs match, which means that the
code that we want to have run, is what has

been executed. This means if someone
manages to overwrite the, the non-write

protected part of the ROM, that would
change those measurements and the TPM

won't reveal the key to them. It also
takes a user password and that password is

validated by the TPM hardware itself,
which gives us hardware rate-limiting on

how often an attacker can try. It also
gives us the ability to do hardware-based

retry limits, so that the TPM will flush
the key, if they if an attacker in

possession of your machine tries too long.
That does mean there's now another way to

lose your disk encryption key.
And there's the the old joke about there

are two types of people with encrypted
drives - those who have lost data due to

forgetting their key, and and those who
will. So what "Heads" does, when you

generate your key, is, it takes that key
and splits it into multiple pieces, that

you can then share either to friends or to
backup services, where each piece doesn't

let you decrypt it. But you can combine
them with Shamir secret sharing to

regenerate the cryptographic disk
encryption key.

We're also able to take advantage of best
practices like using the, including the

disk encryption key headers in the PCRs
that we use to seal the disks. This avoids

a certain class of Evil Maid attack, where
someone swaps out your drive; may not be

in your threat model, but it is easy to
deal with just a few lines of shell

script. So we hopefully we now trust that
the system is running the code we think it

is, but how does it prove to us that it is
actually our machine, that someone hasn't

snuck into our hotel room and swapped out
everything and left, left up, carefully

replaced our stickers to make us believe
we're typing our password into to our own

computer. Some anti-Evil Maid toolkits
will encrypt a secret, secret phrase, and

then display it to you if and only if the
PCR is match, but that's subject to a

replay attack. What Matthew Garrett
demonstrated last year at 32C3, was, using

the time, a time-based one-time password
used by Google Authenticator to protect

the firmware and have it attest to the
user, that it is unmodified. So when the

system boots, and it goes through
measuring all of the various components

the, the TPM will only release the secret
if those PCRs match. The firmware then

hashes that along with the current time
and generates a six digit value that it

prints on the screen. You compare that to
what's on your phone and that tells you

whether or not you can trust the machine.
It's a, it's a great idea, and it's

implemented again as a very small shell
script to read, read the value from the

TPM, unseal it and then compute the
the hash of it.

This also allows us to start making a
transition from the TPM-rooted, a TPM

static route of trust to a PGP-based
trust, where most importantly, this is a

TPM key - excuse me, this is a PGP key,
that you, the owner of the computer

control, not some random vendor or some
random hardware device manufacturer that's

going to lose the key and allow malware
like Stuxnet to use it to circumvent

security. The boot script
in "Heads", again, it's a

small shell script, is able to use a GPG
to verify the next stages of the, the

hypervisor, the initial RAM disk and the
kernel. And it also then uses the the

TPM's counters to help prevent against
rollback, where someone takes your drive

and rolls it back to a previous version,
perhaps with a vulnerability that they can

exploit. So this, this
allows the, allows us to be

sure, that not only are we running the
firmware, the OS that we think we should

be running, it ensures us that someone
hasn't been able to substitute one that, a

vulnerable version. Having the
PGP key also allows us to take

advantage of an idea from Android and
Chrome OS which is the the dm-verity read-

only root filesystem - this hashes all of
the blocks and that hashes all of the the

hashes and so on up until it gets to a
root hash in the tree that is then signed.

This allows the kernel, on every read
access, in logarithmic time to verify the

essentially a signature on that data. This
does require a read-only root filesystem,

but it gives us even more confidence that
the system has been untampered with. Once

you're running your OS, it's good to have
you know some security conscious thoughts

as well, you know. Heads is mostly focused
on, "how do we securely transition to an

OS" and that OS you run is up to you. I
like Qubes - it's reasonably secure, it's

highly recommended by people who know
about endpoint security. And the Qubes

team recognizes that firmware security is
a vital piece of system security. For

their next release, Qubes are for -
they're going to require the machines have

open source firmware, such as coreboot.
And I hope that Heads is going to be a

piece of that. I've also been working with
with the Qubes software and have modified

it to work with things like the dm-verity
read-only root filesystem. This now allows

the user to lock down the configuration,
so that someone can't tamper with their

their setup. It also gives you a recovery
mode that allows you to fix things up and

re-sign the OS. Reproducible builds are
really important so that everyone can

verify what that the builds match what
they should. In the case of of Heads we

have a lot of upstream dependencies that
aren't reproducible so we're working with

them to try to patch them. We've patched
Xen - they've accepted that commit. We've

also built some tools to let you build
initial RAM disks in a reproducible way.

This works with Qubes, with Heads, and
we're hoping to other Linux distributions

pick it up as well.
All of our tree is cryptographically

signed, so hopefully GitHub is not trying
to slip in any patches. And it is open

source so we encourage anyone to read
through it. No NDA is required, unlike most

of the UEFI sources. So that's sort of the
state of where things are - it's pretty

much in very beta, but it is usable. But
there are a lot of areas where we could

continue to do research - things like the
embedded controllers on Chromebooks are

open source. We can use those to help with
our root of trust as well. Porting

coreboot to more modern platforms would
let us take advantage of things like

tamper switches and Intel Boot Guard. I'm
also working on porting coreboot over to

server platforms so that we can use it for
more secure cloud hosting. Servers have a

very different threat model from from
laptops, and a lot of things have firmware

that we have to be concerned about. One
collaboration I'm looking at there is with

the open BMC project to be able to take
advantage of the open source in the

management controller for the servers. And
I'm also collaborating with the Mass Open

Cloud project that's trying to build
secure bare metal clouds. I'm cautiously

optimistic about enclaves and how they
will help us with the security, especially

in a environment where we control the
firmware and we can ensure that the

enclaves are set up in a safe way. There
are a lot of issues on GitHub, again,

please welcome contributions. I hope
everyone gets inspired to to work on the

installing this on their laptop. And if if
you are interested I'll be hanging out at

the coreboot assembly later today and
occasionally this week. The coreboot team

has a bunch of people here. They have
flash programmers and can help you install

coreboot on your laptop. The source code
for Heads is available on GitHub, and a

annotated version of this talk is up on my
website, and welcome comments and feedback

on it. So thank you all for coming to hear
about this project I hope that everyone is

and you know as excited about open source
firmware as I am and I'd love to take any

questions that you all have.

Applause

Question: Thanks for your great talk -
this is very interesting. Do you have any

advice for the 95% of us who are stuck on
non coreboot compatible laptops.

Trammell: Buy a Chromebook?
Laughter

Trammell: It's hard to trust the closed-
source firmware. It certainly; there are

people we have to trust - there are
institutions we have to trust. We have to

trust Intel to some extent, and Intel is
responsible for, you know, both our CPUs

and a lot of the firmware. Depending on
your threat model, firmware attacks may

not be a huge concern for your particular
machine. Or they might be, you know, of

grave concern, in which case even just
doing some of the things that Peter Stuge

suggested of clipping the write-protect
pin on the on the chip, removing things

that might be hostile and attacking your
system. His guides are really good one to

follow for the hardware security.
Question: I was wondering if you also

support ARM - I just saw Intel laptops so
I was just wondering.

Trammell: So ARM it has a lot of
advantages as a CPU. It only has 20 years

of legacy baggage rather than 40. And the
boot process on it is much much simpler

since it doesn't have to go through real
mode to long mode to paging and all the

other steps. The downside to a lot of ARMs
is that they their boot code is a few is

on die and outside of the control of the
user. Luckily, most of that boot code is

fairly simple, and can establish - and
some of them will establish a hardware

root of trust. But in general, yeah that
the ARM to U-Boot to whatever seems to

work out pretty well. I know there's been
some interest in, "can U-Boot be replaced

with a Linux BIOS or coreboot like thing",
and I suspect the folks at the booth would

be able to talk more about that.
Question: And then just a followup - so if

coreboot or Libreboot supports the
platform - Heads will work too right?

Trammell: Essentially yes, yeah.
Heads is a payload for coreboot.

Question: OK.
Herald: It's there on the left.

Signal Angel: Thank you - there's a
question from the Internet about coreboot.

Coreboot has blobs included and, for
example, binary blobs from Intel with all

the firmware support package and all that
stuff. How can we call coreboot secure,

then, in the light of this - let alone
open source?

Trammell: So the intel FSP is a
significant concern. This is the firmware

support package that is required to
initialize the memory controllers on on

modern Intel cpus. On older CPUs, such as
the the Sandy Bridge and Ivy Bridge, the

coreboot and Libreboot are able to
initialize the memory natively without

having to go into the FSB. However, if you
look at what coreboot is doing in the MRC

on those platforms, it tends to just be
poking a bunch of registers with values

that seem to work. And it's modern memory
controllers are so complex that, and Intel

is unwilling to document them, that
without extensive NDA's that it's very

hard to build any sort of memory
initialization. So what we can't say it's

a hundred percent free software, we can at
least we can ensure that the FSP is

measured and it's unchanging. We can also
look at the state of things that it sets

up and include those in our measurements.
So even if it doesn't get us one hundred

percent open source - and as far as I know
the only system that does that right now

is bunnies' Novena laptop. At least we can
measure it and we can know that it hasn't

been tampered with from
what we initially installed.

Question: And before so this is a great
project and I'd like to ask why you did

certain architectural decisions. The
specific combination of Linux and shell.

So why didn't you choose a BSD kernel which
are usually perceived to be more secure

and of a higher quality, and why did you
choose a shell over let's say, Python

or Haskell, which are also often
perceived of higher quality?

Trammell: There is a lot of desire to
support Python in Heads. The downside is

that there's a very limited space: the
X230 bootrom, for instance, has 4

megabytes of available space. The Python
interpreter is a couple megs already. In

terms of why Linux over BSD - the kexec
system call is a core component of this:

to be able to do a graceful shut down and
transfer from the Linux kernel to another

kernel or - to any multi-boot compliant
kernels, which includes BSD. It is a

necessary feature if it, if BSD had such
functionality, that it would be a fine

just a choice for the the internal boot
ROM/boot loader.

Question: Thanks for great work. How to
perform updates of coreboot and its

payload when it's binaries used in
measurement for releasing encryption key

then when you update coreboot this
measurement will change and you will know

no longer will be able to boot the system
- how to solve that problem?

Trammell: So migrating encryption keys
with TPM requires a explicit step of

retrieving the key from the TPM with the
current configuration and then resealing

it with the new configuration. One
advantage of a reproducible build is the

hashes of the of all the firmware stages
can be published - it can be pre-computed,

and then the PCR values can be pre-
computed so you can read you can seal the

keys for the new values. In terms of the
update process for the Heads payload - one

of the things that we're working on is
being able to have an even more minimal

heads that has just a USB device driver
that you can boot into, copy your new

payload, and then install that elsewhere
on the chip. And part of that process

would involve resealing any of the keys
that you need to transfer.

Herald: Another question from the
Internet.

Signal Angel: Thank you. On your webpage
you implemented Heads on ThinkPads only.

How much work is still needed to translate
this to, let's say, non-ThinkPads?

Trammell: ThinkPads are really popular
with the security community. It's quite

interesting to look out at you know the
hall here and see how many ThinkPads there

are. And as a result the coreboot
community has been very supportive of

ThinkPads. There's, other than the
ThinkPads and the Chromebooks, there

aren't a lot of devices that support
coreboot out of the box. And that's

something that I hope would change - I
hope that some OEMs would realize there's

value in provide an open source firmware
and move to move to using it. Both as a

cost-saving measure as well as a freedom
measure. In terms of the difficulty

important coreboot to a platform - I
haven't successfully done that yet, but I

suspect the people at the assembly would
be happy to discuss that further.

Question: Would you plan to rework
embedded controller firmware on ThinkPads

because it's remain close at birth which
still has an access to PC bus and probably

couldn't be trusted.
Trammell: So your question is how do we

how do we replace the EC?
Question: Yes do plan to replace EC with

open source firmware as in the
Chromebooks?

Trammell: So the Chromebook has open
source EC. The part of building coreboot

for Chromebook involves installing the ARM
cross compiler to build the EC firmware.

And the Chromebooks actually have a really
elegant protocol for the EC to attest to

the CPU that is running the firmware that
you think it is running. On other

platforms, this would require a lot more
research. The doc; many of the EC chipsets

have data sheets available, so it's
possible to read through and see how they

work. And most of them have updatable
firmware. In case of the ThinkPads,

there's a module in the ThinkPad BIOS that
will do that update. There's, we would

need to figure out what that protocol
looks like.

Question: Sorry yes I mean if you have
working prototype on ThinkPads probably

want to add remaining business open
sources EC on ThinkPads as well in the

first place.
Trammell: I'm sorry, I don't think I

understood your follow-up.
Question: Okay. So if you if you have a

working prototype on ThinkPads and only on
ThinkPads, will you finish somewhat soon

current existing prototype of open source
EC exists in college shade by Lincoln's or

you are playing to extend your work on
other platforms and finish this bits

later.
Trammell: Yeah right now I have not

personally made any progress on the
ThinkPad EC. I was looking into it because

I have a modified keyboard on my ThinkPad
that that needs to updated EC firmware,

but I haven't actually gotten into that.
This is a area of open research

Signal Angel: Thank you, two quick
questions from the IRC - are you planning

to use systemd in the boot process
is the first one

Laughter
Signal Angel: And the second one let's say

you flash your firmware at the Congress
right here with the help of a hardware

programmer. Can you update when there's a
new version or do you have to currently

need the hardware access to update?
Trammell: Right now you can update

afterwards at great risk, because you can
leave the flash writeable, which would

allow you to flash after the fact. We are
still working on a good procedure for

doing software-only firmware updates once
the immutable boot block is installed. And

to the other question - did I mention that
we are really short on space and we don't

want to put any large applications like
systemd on there.

Questioner: It was like good one, thanks.

applause

postroll music

subtitles created by c3subtitles.de
in the year 2018