[00:00.000 --> 00:17.320] Awesome, thank you. [00:17.320 --> 00:23.240] So my voice was destroyed yesterday in the pub, so everyone has to be very quiet. [00:23.240 --> 00:24.240] Awesome. [00:24.240 --> 00:26.240] Good job. [00:26.240 --> 00:33.440] Okay, awesome surprise with the Secure Boot demo, super awesome. [00:33.440 --> 00:35.040] I did not know about it. [00:35.040 --> 00:41.920] Yeah, we were talking about Secure Boot on NixOS, so this was a team effort by this fine [00:41.920 --> 00:46.520] gentleman and the other one over there who were happily coding while we were sitting [00:46.520 --> 00:52.400] on a boat while I was enjoying life. [00:52.400 --> 00:57.280] And all of this happened mostly at the Ocean Sprint in Lanzarote, which was also an epic [00:57.280 --> 01:03.000] event for getting stuff done in the Nix world, I can totally recommend going there. [01:03.000 --> 01:11.280] Yeah, so Secure Boot, I thought I introduced the shortest possible introduction to it that [01:11.280 --> 01:14.720] I can make. [01:14.720 --> 01:19.360] And then we go on, what is this Lanzarote thing and what status is it and how can you [01:19.360 --> 01:21.880] contribute. [01:21.880 --> 01:27.520] But what's Secure Boot, so what's the problem, so imagine you're here at FOSSTEM, your laptop [01:27.520 --> 01:34.600] is encrypted, then you go out to the pub where you scream too loud and you can't talk afterwards. [01:34.600 --> 01:38.720] And while that is going on, your laptop sits in your hotel room alone, minding its own [01:38.720 --> 01:42.840] business and then many hours later you come back and type your passwords in there. [01:42.840 --> 01:48.000] So is this still the software you think it is on your laptop? [01:48.000 --> 01:53.400] And without Secure Boot you don't really know. [01:53.400 --> 01:59.840] So Secure Boot is one solution to this, it's not a complete solution but it mitigates some [01:59.840 --> 02:09.680] of it and the way it works in a very tiny nutshell is that your EFI firmware just verifies [02:09.680 --> 02:10.680] what it's booting. [02:10.680 --> 02:15.120] So it just takes the bootloader, checks the signature, cryptographic signature on it and [02:15.120 --> 02:21.120] then the bootloader has then to look at the operating system it boots and also check a [02:21.120 --> 02:22.400] cryptographic signature on it. [02:22.400 --> 02:27.280] So you have like a chain of trust from your firmware all the way to your operating system [02:27.280 --> 02:35.480] and if this all works then someone else can't easily replace the operating system with something [02:35.480 --> 02:40.280] that your laptop doesn't trust. [02:40.280 --> 02:46.200] Now the question is okay it verifies cryptographic signatures with what? [02:46.200 --> 02:55.600] And typically if you buy a laptop it will trust the Microsoft CAA and some OEM CAA. [02:55.600 --> 03:00.960] And this is fine for Windows obviously and it's also fine for some of the other big distros [03:00.960 --> 03:05.480] so you can take a Ubuntu and it works on a Secure Boot laptop, you can take a Fedora [03:05.480 --> 03:12.600] it just works, unfortunately for NixOS it does not. [03:12.600 --> 03:21.200] So what's the issue with Secure Boot and NixOS, I think fundamentally it's a very different [03:21.200 --> 03:27.200] model from other Linux distributions there's not like a, there is like a thing that centrally [03:27.200 --> 03:32.080] builds packets and you can download it from somewhere but it's mostly build cache, you [03:32.080 --> 03:33.200] don't have to use it. [03:33.200 --> 03:41.440] You can build all of this locally and also you can do, it's so configurable so what would [03:41.440 --> 03:46.920] you even, so it's very easy to end up with an init rd that is not cached over the kernel [03:46.920 --> 03:52.160] that's not cached on cache.nixos and then you will obviously not get signed binaries [03:52.160 --> 03:58.880] even if cache.nixos would sign them which it does not for Secure Boot. [03:58.880 --> 04:07.120] So for now we're targeting your own CA so you can just say fuck it, I will enroll my [04:07.120 --> 04:10.360] own keys to the firmware. [04:10.360 --> 04:16.640] This is scary, it also looks scary if you do it but it works reasonably well. [04:16.640 --> 04:20.840] But then comes the question, every time I change the software on my laptop I just have [04:20.840 --> 04:25.640] to manually sign it and that sucks, no one wants to do that. [04:25.640 --> 04:30.400] So now we come to what is this lanza-botel thing actually, this is actually the tooling [04:30.400 --> 04:35.640] that makes all of this convenient for nixos so lanza-botel takes care of automatically [04:35.640 --> 04:45.440] re-signing your system d boot, your kernel, whenever you do nixos rebuild, this is a one [04:45.440 --> 04:46.680] line description of it. [04:46.680 --> 04:53.360] It does not take care of generating keys initially, it does not take care of enrolling them in [04:53.360 --> 04:58.520] the firmware, this is something the user has to do once right now. [04:58.520 --> 05:03.760] We have quick start documentation for that, so I've heard that it has worked for other [05:03.760 --> 05:04.760] people. [05:04.760 --> 05:18.440] Not bad, I have also heard that it did not work for other people but so far I think the [05:18.440 --> 05:24.920] likelihood of trashing your system with it has been very low, Niklas was very busy fixing [05:24.920 --> 05:31.360] the onboarding device. [05:31.360 --> 05:37.840] All of this revolves around unified kernel images, this is pretty recent technology out [05:37.840 --> 05:46.520] of the system d sphere, a unified kernel image is a normal UEFIPE file that can just be booted [05:46.520 --> 05:54.040] by the firmware with some extra bits, so it's basically a tiny archive of Linux kernel, [05:54.040 --> 05:59.600] the Linux kernel's command line, and then it also contains some meta information, so [05:59.600 --> 06:05.200] there's an OS release file in there and it has the name of this thing, the version and [06:05.200 --> 06:12.480] this is basically used to generate the entry in the menu when you select what to boot in [06:12.480 --> 06:14.520] system d boot. [06:14.520 --> 06:18.960] And then because it's all self-contained you just sign this one thing and you're good with [06:18.960 --> 06:23.960] secure boot. [06:23.960 --> 06:32.160] As we see grub support is nearing completion and also Ryan keeps telling me Linux support [06:32.160 --> 06:38.720] is also planned, but so far system d boot is the thing to go. [06:38.720 --> 06:45.320] Now to the sort of, so there is a PE stub, so to form a unified kernel image you have [06:45.320 --> 06:51.600] to stub on some PE image, some PE binary at the front, there's one from system d, it's [06:51.600 --> 06:57.120] called system d stub, and it basically does exactly what I just told you, so you have [06:57.120 --> 07:01.480] like the stub at the front, then the command line, the kernel init-rd and the OS release [07:01.480 --> 07:05.840] which I ignored on this picture, and it works. [07:05.840 --> 07:14.160] The problem for NixOS is that this kernel command line basically contains a store path [07:14.160 --> 07:22.640] that changes for every NixOS generation, so whenever you do NixOS rebuild, if you experiment [07:22.640 --> 07:31.000] with your system a bit, you will have a new one of these files in your slash boot directory. [07:31.000 --> 07:35.280] This is problematic because you also have the kernel and init-rd in this one blob and [07:35.280 --> 07:42.680] at least for me there are around 40 megabytes, and the typical system partition, the slash [07:42.680 --> 07:51.200] boot thing is like half a gigabyte, so I've seen NixOS systems with many generations, [07:51.200 --> 08:01.760] I point at you, and running out of space in your boot partitions is very uncomfortable, [08:01.760 --> 08:08.640] so that's why we wrote the Lancelot boot stub, it's basically, it does the same as [08:08.640 --> 08:16.440] the system d stub, just that you don't have to embed the file, the content of kernel and [08:16.440 --> 08:23.680] init-rd anymore, you just embed a path to the file and the cryptographic hash to it, [08:23.680 --> 08:30.080] so basically just point somewhere and say what you expect to be at that location. [08:30.080 --> 08:34.960] So then on the boot partition you also have these files and then you're good, so the stub [08:34.960 --> 08:42.720] will get the file name, load the file, check the hash and if everything works out, it gets [08:42.720 --> 08:49.480] booted, and since the hashes are assigned, this is as secure as before. [08:49.480 --> 08:54.560] And now the nice thing is that this stub is now only like 100 kilobytes in size and you [08:54.560 --> 09:00.240] can have another one that has a different command line, but may use the same kernel and same [09:00.240 --> 09:05.480] init-rd and you just, for this new generation, you just get another 100 kilobytes instead [09:05.480 --> 09:15.440] of 40 megabytes and now Ryan can have his 600 generations again in his boot folder. [09:15.440 --> 09:22.520] So obviously maintaining our own stub is not something that we enjoy too much, so there [09:22.520 --> 09:30.000] are discussions ongoing in the system debug tracker to upstream this functionality that [09:30.000 --> 09:35.560] you can just reference files on the boot partition instead of embedding them in the system d-stub [09:35.560 --> 09:44.640] and then system d-stub would just supersede the lancer-botar-stub and everyone is happy. [09:44.640 --> 09:53.440] No, the other, I said, awesome, the German is strong. [09:53.440 --> 09:57.520] So this is like the boot part of the whole secure boot tool chain, but then there's also [09:57.520 --> 10:07.560] like the nix part of it, big thing is the lancer-botar-tool, this is what is being called when you call [10:07.560 --> 10:15.560] nixOS rebuild and what it basically does is it takes all the different generations you [10:15.560 --> 10:26.560] have in your nixOS and assembles the lancer-botar-stubs and prepares the boot partition and signs [10:26.560 --> 10:27.560] everything. [10:27.560 --> 10:35.560] This is pretty involved due to non-reproducibility of kernel, so it's a bit tricky at times [10:35.560 --> 10:42.080] and we had some issues with that, but I think we're basically down to some polishing at [10:42.080 --> 10:45.880] this point to get this right. [10:45.880 --> 10:53.480] So we also depend on the boot spec RFC, which is at the moment an experimental feature in [10:53.480 --> 11:00.000] nix packages in nixOS where for each generation you get a nice JSON file describing which [11:00.000 --> 11:04.760] kernel which init-rd you want to boot and then the bootloader-tooling can just take [11:04.760 --> 11:07.520] the JSON and do whatever it needs to do. [11:07.520 --> 11:11.680] So this has been also pretty nice. [11:11.680 --> 11:16.680] Yeah, how to use this? [11:16.680 --> 11:24.280] As I said you have to do some manual step to onboard, we've tried to document them as [11:24.280 --> 11:27.000] user-friendly as possible given the topic. [11:27.000 --> 11:32.520] You are expected to be able to use nixOS, you are expected to be able to restore your [11:32.520 --> 11:38.520] system from a backup if everything goes wrong, but other than that you should be able to [11:38.520 --> 11:42.080] set this up if you want to. [11:42.080 --> 11:46.720] Of course if you want this to be an actual security feature then you may want to come [11:46.720 --> 11:50.760] back later, but if you really, really want to use it as a security feature you definitely [11:50.760 --> 11:56.520] need a BIOS password otherwise someone can just turn secure boot off and then you also [11:56.520 --> 12:00.760] need full disk encryption because otherwise someone can just read the private keys from [12:00.760 --> 12:05.520] your disk. [12:05.520 --> 12:14.280] But that being said when it all works it's not much more than SPCTL create keys, enrolling [12:14.280 --> 12:26.280] them after going to the BIOS menu and some very benign nixOS configuration. [12:26.280 --> 12:32.800] Yeah, that's it, so I didn't want to go into too much technical things, you can ask me [12:32.800 --> 12:40.520] about stuff, otherwise you can use it today, so I have this running, so if I type device [12:40.520 --> 12:53.360] security then you don't see anything, then I have to exit this and you see that for me [12:53.360 --> 12:58.520] your boot is active. [12:58.520 --> 13:05.560] As far as collaboration goes, I have to find the button again, the discussion mostly happens [13:05.560 --> 13:13.200] on the GitHub repository, open issues, we respond reasonably fast, we're currently in [13:13.200 --> 13:21.920] the process of fixing all the bugs and I think when we're bug free we will just call [13:21.920 --> 13:25.960] it 1.0 and then afterwards there's like a million features that people want and they [13:25.960 --> 13:30.120] will all be very cool, but bugs need to be fixed. [13:30.120 --> 13:34.680] First, we discuss on matrix in the secure boot channel, there are a couple of other [13:34.680 --> 13:39.920] matrix, there are too many security related matrix channels, you just join all of them [13:39.920 --> 13:44.720] and then it's fine, there's one about boot spec then there's one about nixOS and TPMs [13:44.720 --> 13:48.160] that I forgot to put on the slide. [13:48.160 --> 13:54.320] Rust OS stuff has been helpful for the Rust UEFI development, there's a very nice community [13:54.320 --> 14:02.800] over there for Rust UEFI programming and you can also just ping me personally on matrix [14:02.800 --> 14:10.640] or on mastodon and it should also not be hard to find my Twitter handle somewhere. [14:10.640 --> 14:23.520] So that's it, I'm happy to take questions, oh so many. [14:23.520 --> 14:39.160] So what I personally find very nice is, the question was whether I can speculate on the [14:39.160 --> 14:45.240] cool features that are about to come and personally I find all the TPM stuff very exciting and [14:45.240 --> 14:49.400] the problem is mostly that the tooling is completely horrific and all the documentation [14:49.400 --> 15:02.200] and terminology is like, it's annoying on purpose, so I'm really eager to make this [15:02.200 --> 15:09.000] usable for people that don't want to know all the details about TPMs, so for example [15:09.000 --> 15:14.920] you want your disk encryption to be unlocked if your system has not been tempered with. [15:14.920 --> 15:20.680] This is like a, I mean not tempered with is a complicated thing to define so and usability [15:20.680 --> 15:23.920] aspects are hard, but this is something I would really want, so if my laptop is in [15:23.920 --> 15:29.720] good condition and my TPM believes everything is good then I don't want to type in my password [15:29.720 --> 15:48.280] again, yeah then the whole, the question is whether we have tested it with Corbut, no [15:48.280 --> 16:05.240] if you deploy Corbut with a UFI payload it should just work, I mean it worked for buggy [16:05.240 --> 16:31.840] UFI, we are compliant too I think, so if you use the Tianokou EDK2 on Corbut it should [16:31.840 --> 16:56.360] work because this is also what we use in QMU for testing. [16:56.360 --> 17:01.960] So using it without an encrypted disk, so first issue if you don't put a private key on it [17:01.960 --> 17:08.080] and do the signing some way, somehow else, which we don't support right now, you could [17:08.080 --> 17:14.840] at least avoid this problem, but then there's the issue if you don't have integrity protection [17:14.840 --> 17:33.000] for your disk, someone can just replace whatever's on your disk and boot some other kernel. [17:33.000 --> 17:37.800] So the thing is, so secure boot is like one aspect of a secure system and whenever we [17:37.800 --> 17:43.720] start to talk about it, someone comes and wants the whole flower bouquet, so what you [17:43.720 --> 17:50.720] say is it's definitely possible, but somewhat out of scope for the secure boot effort. [17:50.720 --> 18:16.720] Thank you very much for your time, thank you very much for your time, thank you very much.