Awesome, thank you.
So my voice was destroyed yesterday in the pub, so everyone has to be very quiet.
Awesome.
Good job.
Okay, awesome surprise with the Secure Boot demo, super awesome.
I did not know about it.
Yeah, we were talking about Secure Boot on NixOS, so this was a team effort by this fine
gentleman and the other one over there who were happily coding while we were sitting
on a boat while I was enjoying life.
And all of this happened mostly at the Ocean Sprint in Lanzarote, which was also an epic
event for getting stuff done in the Nix world, I can totally recommend going there.
Yeah, so Secure Boot, I thought I introduced the shortest possible introduction to it that
I can make.
And then we go on, what is this Lanzarote thing and what status is it and how can you
contribute.
But what's Secure Boot, so what's the problem, so imagine you're here at FOSSTEM, your laptop
is encrypted, then you go out to the pub where you scream too loud and you can't talk afterwards.
And while that is going on, your laptop sits in your hotel room alone, minding its own
business and then many hours later you come back and type your passwords in there.
So is this still the software you think it is on your laptop?
And without Secure Boot you don't really know.
So Secure Boot is one solution to this, it's not a complete solution but it mitigates some
of it and the way it works in a very tiny nutshell is that your EFI firmware just verifies
what it's booting.
So it just takes the bootloader, checks the signature, cryptographic signature on it and
then the bootloader has then to look at the operating system it boots and also check a
cryptographic signature on it.
So you have like a chain of trust from your firmware all the way to your operating system
and if this all works then someone else can't easily replace the operating system with something
that your laptop doesn't trust.
Now the question is okay it verifies cryptographic signatures with what?
And typically if you buy a laptop it will trust the Microsoft CAA and some OEM CAA.
And this is fine for Windows obviously and it's also fine for some of the other big distros
so you can take a Ubuntu and it works on a Secure Boot laptop, you can take a Fedora
it just works, unfortunately for NixOS it does not.
So what's the issue with Secure Boot and NixOS, I think fundamentally it's a very different
model from other Linux distributions there's not like a, there is like a thing that centrally
builds packets and you can download it from somewhere but it's mostly build cache, you
don't have to use it.
You can build all of this locally and also you can do, it's so configurable so what would
you even, so it's very easy to end up with an init rd that is not cached over the kernel
that's not cached on cache.nixos and then you will obviously not get signed binaries
even if cache.nixos would sign them which it does not for Secure Boot.
So for now we're targeting your own CA so you can just say fuck it, I will enroll my
own keys to the firmware.
This is scary, it also looks scary if you do it but it works reasonably well.
But then comes the question, every time I change the software on my laptop I just have
to manually sign it and that sucks, no one wants to do that.
So now we come to what is this lanza-botel thing actually, this is actually the tooling
that makes all of this convenient for nixos so lanza-botel takes care of automatically
re-signing your system d boot, your kernel, whenever you do nixos rebuild, this is a one
line description of it.
It does not take care of generating keys initially, it does not take care of enrolling them in
the firmware, this is something the user has to do once right now.
We have quick start documentation for that, so I've heard that it has worked for other
people.
Not bad, I have also heard that it did not work for other people but so far I think the
likelihood of trashing your system with it has been very low, Niklas was very busy fixing
the onboarding device.
All of this revolves around unified kernel images, this is pretty recent technology out
of the system d sphere, a unified kernel image is a normal UEFIPE file that can just be booted
by the firmware with some extra bits, so it's basically a tiny archive of Linux kernel,
the Linux kernel's command line, and then it also contains some meta information, so
there's an OS release file in there and it has the name of this thing, the version and
this is basically used to generate the entry in the menu when you select what to boot in
system d boot.
And then because it's all self-contained you just sign this one thing and you're good with
secure boot.
As we see grub support is nearing completion and also Ryan keeps telling me Linux support
is also planned, but so far system d boot is the thing to go.
Now to the sort of, so there is a PE stub, so to form a unified kernel image you have
to stub on some PE image, some PE binary at the front, there's one from system d, it's
called system d stub, and it basically does exactly what I just told you, so you have
like the stub at the front, then the command line, the kernel init-rd and the OS release
which I ignored on this picture, and it works.
The problem for NixOS is that this kernel command line basically contains a store path
that changes for every NixOS generation, so whenever you do NixOS rebuild, if you experiment
with your system a bit, you will have a new one of these files in your slash boot directory.
This is problematic because you also have the kernel and init-rd in this one blob and
at least for me there are around 40 megabytes, and the typical system partition, the slash
boot thing is like half a gigabyte, so I've seen NixOS systems with many generations,
I point at you, and running out of space in your boot partitions is very uncomfortable,
so that's why we wrote the Lancelot boot stub, it's basically, it does the same as
the system d stub, just that you don't have to embed the file, the content of kernel and
init-rd anymore, you just embed a path to the file and the cryptographic hash to it,
so basically just point somewhere and say what you expect to be at that location.
So then on the boot partition you also have these files and then you're good, so the stub
will get the file name, load the file, check the hash and if everything works out, it gets
booted, and since the hashes are assigned, this is as secure as before.
And now the nice thing is that this stub is now only like 100 kilobytes in size and you
can have another one that has a different command line, but may use the same kernel and same
init-rd and you just, for this new generation, you just get another 100 kilobytes instead
of 40 megabytes and now Ryan can have his 600 generations again in his boot folder.
So obviously maintaining our own stub is not something that we enjoy too much, so there
are discussions ongoing in the system debug tracker to upstream this functionality that
you can just reference files on the boot partition instead of embedding them in the system d-stub
and then system d-stub would just supersede the lancer-botar-stub and everyone is happy.
No, the other, I said, awesome, the German is strong.
So this is like the boot part of the whole secure boot tool chain, but then there's also
like the nix part of it, big thing is the lancer-botar-tool, this is what is being called when you call
nixOS rebuild and what it basically does is it takes all the different generations you
have in your nixOS and assembles the lancer-botar-stubs and prepares the boot partition and signs
everything.
This is pretty involved due to non-reproducibility of kernel, so it's a bit tricky at times
and we had some issues with that, but I think we're basically down to some polishing at
this point to get this right.
So we also depend on the boot spec RFC, which is at the moment an experimental feature in
nix packages in nixOS where for each generation you get a nice JSON file describing which
kernel which init-rd you want to boot and then the bootloader-tooling can just take
the JSON and do whatever it needs to do.
So this has been also pretty nice.
Yeah, how to use this?
As I said you have to do some manual step to onboard, we've tried to document them as
user-friendly as possible given the topic.
You are expected to be able to use nixOS, you are expected to be able to restore your
system from a backup if everything goes wrong, but other than that you should be able to
set this up if you want to.
Of course if you want this to be an actual security feature then you may want to come
back later, but if you really, really want to use it as a security feature you definitely
need a BIOS password otherwise someone can just turn secure boot off and then you also
need full disk encryption because otherwise someone can just read the private keys from
your disk.
But that being said when it all works it's not much more than SPCTL create keys, enrolling
them after going to the BIOS menu and some very benign nixOS configuration.
Yeah, that's it, so I didn't want to go into too much technical things, you can ask me
about stuff, otherwise you can use it today, so I have this running, so if I type device
security then you don't see anything, then I have to exit this and you see that for me
your boot is active.
As far as collaboration goes, I have to find the button again, the discussion mostly happens
on the GitHub repository, open issues, we respond reasonably fast, we're currently in
the process of fixing all the bugs and I think when we're bug free we will just call
it 1.0 and then afterwards there's like a million features that people want and they
will all be very cool, but bugs need to be fixed.
First, we discuss on matrix in the secure boot channel, there are a couple of other
matrix, there are too many security related matrix channels, you just join all of them
and then it's fine, there's one about boot spec then there's one about nixOS and TPMs
that I forgot to put on the slide.
Rust OS stuff has been helpful for the Rust UEFI development, there's a very nice community
over there for Rust UEFI programming and you can also just ping me personally on matrix
or on mastodon and it should also not be hard to find my Twitter handle somewhere.
So that's it, I'm happy to take questions, oh so many.
So what I personally find very nice is, the question was whether I can speculate on the
cool features that are about to come and personally I find all the TPM stuff very exciting and
the problem is mostly that the tooling is completely horrific and all the documentation
and terminology is like, it's annoying on purpose, so I'm really eager to make this
usable for people that don't want to know all the details about TPMs, so for example
you want your disk encryption to be unlocked if your system has not been tempered with.
This is like a, I mean not tempered with is a complicated thing to define so and usability
aspects are hard, but this is something I would really want, so if my laptop is in
good condition and my TPM believes everything is good then I don't want to type in my password
again, yeah then the whole, the question is whether we have tested it with Corbut, no
if you deploy Corbut with a UFI payload it should just work, I mean it worked for buggy
UFI, we are compliant too I think, so if you use the Tianokou EDK2 on Corbut it should
work because this is also what we use in QMU for testing.
So using it without an encrypted disk, so first issue if you don't put a private key on it
and do the signing some way, somehow else, which we don't support right now, you could
at least avoid this problem, but then there's the issue if you don't have integrity protection
for your disk, someone can just replace whatever's on your disk and boot some other kernel.
So the thing is, so secure boot is like one aspect of a secure system and whenever we
start to talk about it, someone comes and wants the whole flower bouquet, so what you
say is it's definitely possible, but somewhat out of scope for the secure boot effort.
Thank you very much for your time, thank you very much for your time, thank you very much.