WEBVTT 00:00.000 --> 00:11.680 Thanks very much for coming, is audio okay, great, thanks. 00:11.680 --> 00:16.760 So we're presenting basically how we can use ComposerVas, which is sort of a new type of 00:16.760 --> 00:24.440 file system in for containers and root files system of metal systems, with UKI to produce 00:24.440 --> 00:29.920 a chain of trust all the way through to the root files system from Secure Boot. 00:29.920 --> 00:33.360 This is just like a figure of expression in English, if you don't know it, it's basically 00:33.360 --> 00:37.120 the idea that if you deliver something to somebody, they should be able to trust that 00:37.120 --> 00:39.080 it wasn't tampered on the way. 00:39.080 --> 00:44.480 So yeah, just like I said, you know, we got Secure Boot, we can verify the kernel, 00:44.480 --> 00:51.800 the init RAM-a-fass, but as soon as you like hit a knit, it can do whatever it wants. 00:51.800 --> 00:54.040 And you can't really trust the system that's based on that. 00:54.040 --> 00:57.600 And this is a goal, this is something that's come up over and over again, people talk about it 00:57.600 --> 01:01.560 a lot, we need to be able to trust the root files system, it needs to be immutable, and 01:01.560 --> 01:03.480 it needs to be verified. 01:03.480 --> 01:09.320 So what is ComposerVas, the say this is point to you, you can like I'll leave now, it doesn't 01:09.320 --> 01:19.480 exist, but it tried to exist, guy named Alex and went on LKML once upon a time, and 01:19.480 --> 01:22.440 LKML is kind of a fun place sometimes. 01:22.440 --> 01:27.400 And he had this great idea and it was just like, yeah, no, sorry, not going to happen. 01:27.400 --> 01:31.000 But here's why it's not going to happen, because if you kind of look at, you know, overlay 01:31.000 --> 01:35.160 a fast kind of sound similar to what you're doing, and with, like, FSVarity and stuff, 01:35.160 --> 01:37.800 we could make something work here. 01:37.800 --> 01:45.320 Yes, FSVarity, for people who don't know, it's basically a way of you can verify the contents 01:45.320 --> 01:48.880 of a file down to a single hash. 01:48.880 --> 01:55.080 And it's supported by regular file systems, more are increasingly supporting it, so 01:55.080 --> 01:59.320 far, like the most common ones already do. 01:59.320 --> 02:01.440 And yeah, unfortunately, it doesn't do directories and stuff. 02:01.440 --> 02:05.560 So basically, you're in a situation where you have a regular file. 02:05.560 --> 02:10.800 You can't trust its metadata, you can't trust the layout of the file system, but if you 02:10.800 --> 02:14.120 have that one regular file and you open it, and you're going to read its contents, you 02:14.120 --> 02:16.600 can at least know what contents you're going to get. 02:16.600 --> 02:21.920 And that works by measuring the file, which is built on a maclotry. 02:21.920 --> 02:26.240 And the reason that sound is for efficiency, when you pull in a single block of the file, 02:26.240 --> 02:28.920 you don't want to have to hash the entire file. 02:28.920 --> 02:34.440 So it basically builds that up, and then has a descriptor that's necessary for technical 02:34.440 --> 02:38.240 reasons to make sure that files are different sized, don't hash to the same thing. 02:38.240 --> 02:40.160 And then you get the MSVarity digest. 02:40.160 --> 02:41.680 You have to enable that profile. 02:41.680 --> 02:44.240 Once you turn it on for a file, you can never turn it off again. 02:44.240 --> 02:47.040 You can basically delete the file, and that's it. 02:47.040 --> 02:51.560 And then once it's enabled, you can basically say directly, hey, tell me what the digest 02:51.640 --> 02:53.040 of this file is. 02:53.040 --> 02:57.680 And you get that, and as long as you have that FD in your hand, you know, the I-NOS 02:57.680 --> 03:02.320 not changing, it's immutable, you will read that content. 03:02.320 --> 03:06.840 So EROFS is probably the least interesting part of all of this. 03:06.840 --> 03:09.560 It's just another read-only file system. 03:09.560 --> 03:14.200 We like it because the maintainers are really nice, and it has the features we need, 03:14.200 --> 03:18.920 and it's specifically a performance for the use cases we care about. 03:18.920 --> 03:23.320 OverlayFS, probably most people here are kind of aware of what that is. 03:23.320 --> 03:27.000 It's, you know, you upper layer lower layer, and then I go in, like, access file A. 03:27.000 --> 03:32.280 It checks an upper layer, do I have A. If not, then it falls through to the lower layer. 03:32.280 --> 03:36.000 And you use this for, like, you know, if you want a base image usually, and you want 03:36.000 --> 03:39.040 to do modifications to it, then you can do an overlayFS. 03:39.040 --> 03:43.160 And the modifications will only go in the top part, and it's basically serving as a diff. 03:43.160 --> 03:48.240 But, you know, there shouldn't situations you could get into with this naive way that 03:48.280 --> 03:49.720 I've described overlayFS. 03:49.720 --> 03:51.760 Like, what if you want to delete a file? How does that work? 03:51.760 --> 03:55.200 I just said, okay, I look for it in the top one, and if it's not there, you go to the bottom. 03:55.200 --> 03:57.480 If it's in the bottom, how can I make a disappear? 03:57.480 --> 04:00.520 So there's a concept of a way, though, you can start a character device there, if it finds 04:00.520 --> 04:04.640 it, it'll say, okay, this file doesn't exist, because you meant that it got deleted. 04:04.640 --> 04:08.840 Renaming large files is a little bit more complicated, because, like, if I have a very 04:08.840 --> 04:12.800 large file A, and I want to rename it to B, hmm. 04:12.800 --> 04:15.960 Okay, do I have to copy that entire file content up to B? 04:16.000 --> 04:19.040 Fortunately, there's something called the redirect attribute that lets you do that. 04:19.040 --> 04:22.520 And you can basically store that on the file B, and it'll point to file A. 04:22.520 --> 04:26.160 And then when you do a writeout, you can basically move A to B. 04:26.160 --> 04:29.760 And similarly, if you just want to change the metadata on a file, like, you know, 04:29.760 --> 04:33.480 their owner or the permissions or something, then you can use the other attribute. 04:33.480 --> 04:37.480 And something really useful about that is then it will tell you what the original content 04:37.480 --> 04:40.280 should be with FSW if you enable a certain feature. 04:40.280 --> 04:43.600 So it's a way of making sure that also that data didn't change. 04:43.600 --> 04:47.120 And that's, like, really the thing that composes us is absolutely built on the ability 04:47.120 --> 04:51.960 to store this FSW ID digest in the upper file system image. 04:51.960 --> 04:54.560 So basically, we created an undis format. 04:54.560 --> 04:56.960 It looks like this. 04:56.960 --> 05:00.200 Objects are basically just normal files that are hashed by their content. 05:00.200 --> 05:04.960 Using the FSW ID digest, we split the first two characters of the hash as a directory 05:04.960 --> 05:08.680 name just to sort of keep the director's a little bit smaller to optimize lookups. 05:08.680 --> 05:11.360 And images, that's an EROFS image. 05:11.440 --> 05:12.440 And that's a sim link. 05:12.440 --> 05:13.720 It's also stored in the object store. 05:13.720 --> 05:16.320 It has FSW ID enabled, which is going to be important later. 05:16.320 --> 05:19.680 So those locks mean basically FSW ID verified. 05:19.680 --> 05:20.920 And that is the hash value. 05:20.920 --> 05:24.080 So when we open that, we can verify with FSW ID that it actually hashes 05:24.080 --> 05:26.240 to A3, whatever. 05:26.240 --> 05:28.160 OK, so let's mount that. 05:28.160 --> 05:30.480 That's what it looks like inside just our example. 05:30.480 --> 05:34.120 And we mount this as the upper layer of part of an overlay if that's layout. 05:34.120 --> 05:36.960 And the lower layer is that object directory. 05:36.960 --> 05:39.640 And now you maybe can kind of see where this is going. 05:39.640 --> 05:44.000 We can use this redirect feature in overlay if that's which is quite handy to say, 05:44.000 --> 05:47.440 OK, bash is actually, we want you to go and get that file. 05:47.440 --> 05:50.200 We pretend that that's what bash was originally called in the lower layer. 05:50.200 --> 05:52.800 But it's basically like we can use that as a pointer to say, 05:52.800 --> 05:54.440 that's where you get your data from. 05:54.440 --> 05:57.240 So this is sort of the core thing that achieves de-duplication in composed of 05:57.240 --> 05:59.680 s, which is a really key issue as well. 05:59.680 --> 06:03.480 And of course, as I mentioned, that FSW ID thing in doing that redirect, 06:03.480 --> 06:05.680 we can add the other extended attribute, which says, 06:05.680 --> 06:07.800 make sure it has that content. 06:07.800 --> 06:13.600 So we've essentially created the situation where the entire content of the file system 06:13.600 --> 06:16.880 is specified by what's in that URL of FSW ID. 06:16.880 --> 06:20.160 Because the layouts there, all of the metadata is there. 06:20.160 --> 06:22.920 And any time we actually go and get the physical blocks from the disk, 06:22.920 --> 06:25.240 we verify them with FSW ID. 06:25.240 --> 06:27.960 So that lock there, and the fact that the image is locked, 06:27.960 --> 06:31.760 means that we have effectively reduced the entire root file system to that hash value 06:31.760 --> 06:33.240 of 33002. 06:33.240 --> 06:37.760 And if any of the content or metadata changed, that hash value would change. 06:37.760 --> 06:41.720 And the really cool part about this is that we can take an entire compose of s, 06:41.720 --> 06:44.240 and we can sort on one root partition, 06:44.240 --> 06:46.440 along with your normal mutable content. 06:46.440 --> 06:48.800 Like if you have your var, let's say whatever. 06:48.800 --> 06:54.640 These are just normal files on normal file system, like X4 or Butterfaster or whatever. 06:54.640 --> 06:58.040 And yeah, you can stick your normal mutable content alongside them. 06:58.040 --> 07:01.560 These files are FSW ID enabled, so you could delete them. 07:01.560 --> 07:02.720 You can mess around with them. 07:02.720 --> 07:05.680 But you can't mutate them when they have FSW ID on them. 07:05.680 --> 07:09.520 And as long as we verify that hash before we do this overlay of FSW ID, 07:09.520 --> 07:12.760 we're pretty sure we're in a safe situation. 07:12.760 --> 07:15.480 So the way that that ends up working, 07:15.480 --> 07:17.240 a pass over to Timothy for this now. 07:31.560 --> 07:49.240 Okay, are we good? 07:49.240 --> 07:51.240 Yeah. 07:51.240 --> 07:54.840 All right, thanks, Jason, for working us through the compose. 07:54.840 --> 07:56.280 How did it structured? 07:56.280 --> 07:59.320 And now we're going to look at how we actually boot a system, 07:59.320 --> 08:04.320 how we take, we go from having a computer-fest image system, 08:04.320 --> 08:05.840 install somewhere on a root partition, 08:05.840 --> 08:10.120 and how we go from that to having a system that we can boot, 08:10.120 --> 08:14.080 and go to verify this image that we're actually booting this one here. 08:14.080 --> 08:18.320 So the first step here is we're going to build a unified kernel image, 08:18.320 --> 08:21.240 a UKI and so for those that don't know. 08:21.240 --> 08:24.720 Ready, UKI is combining a kernel in trial-fest and the kernel 08:24.720 --> 08:28.760 come online into a single binary that we can later sign. 08:28.760 --> 08:32.520 So the main thing here is that we're going to include in the kernel 08:32.520 --> 08:37.760 kernel line, the hash of the compiler-fest image that we are going to be booting. 08:37.760 --> 08:41.320 So in there you have the hash, you know that you're going to be booting 08:41.320 --> 08:44.920 only this one here, and because of it, we know the hash of the compiler-fest, 08:44.920 --> 08:49.640 we know the full content of the root file system. 08:49.640 --> 08:54.040 So now that we have a UKI, we can sign it with SIG for SIG boot, 08:54.040 --> 08:59.040 with KEEZ, we can put it into the ESP, 08:59.040 --> 09:03.040 and then add the classic VITS that you may or may not want, 09:03.040 --> 09:06.640 so SHIB, which is optional, and usually a boot to the layer here, 09:06.640 --> 09:09.040 which is a system-d boot. 09:09.040 --> 09:11.640 And finally, when you boot your system, you go to firmware, 09:11.640 --> 09:16.040 you've downloaded your enrolled your SIG boot keys, 09:16.040 --> 09:19.040 the side of the firmware, it goes through SHIM, system-d boot, 09:19.040 --> 09:23.040 you pick your UKI, and then if everything is verified, yes, 09:23.040 --> 09:26.040 SIG boot, that is quite recent, yes, SIG boot, 09:26.040 --> 09:29.040 and then it keeps on booting. 09:29.040 --> 09:32.040 And so that's how you get the full chain of trust, 09:32.040 --> 09:37.040 is that has you, has the need from FS, looks inside of the kernel command line, 09:37.040 --> 09:39.040 it finds the composite hash hash, 09:39.040 --> 09:43.040 which is the hash of the error-fest image that is stored on the root partition, 09:43.040 --> 09:46.040 and thus you can figure out which version of the system to boot, 09:46.040 --> 09:52.040 and more importantly, which, like, make sure that all of the content 09:52.040 --> 09:56.040 that we're going to be booting is exactly the one that we want. 09:56.040 --> 09:58.040 Everything that all the files are verified, 09:58.040 --> 10:02.040 and that we only booting this one version of the operating system. 10:02.040 --> 10:07.040 So here on SIG here, as I'm saying, we have all of the persistent content, 10:07.040 --> 10:09.040 we stored, we can be stored on the same partition, 10:09.040 --> 10:12.040 so you can be either different beta-fest subvolumes, 10:12.040 --> 10:16.040 or it could even be different, yeah, different, just very directory, 10:16.040 --> 10:19.040 or if, like, once you can still have different partition, 10:19.040 --> 10:24.040 but the cool thing is that you can do seal everything on one place. 10:24.040 --> 10:30.040 So now that's great, we have a full trusted boot chain, 10:30.040 --> 10:32.040 and that we can rely on, 10:32.040 --> 10:34.040 but how do we actually build all of this? 10:34.040 --> 10:38.040 And one option to do that is to, we're working on this, 10:38.040 --> 10:43.040 I'm building it using a container file, so using container native tooling. 10:43.040 --> 10:46.040 You can, as everything here is just files, 10:46.040 --> 10:49.040 you can build this directly as you would build a container. 10:49.040 --> 10:52.040 So you can start with almost any container image, 10:52.040 --> 10:56.040 like a classic container image, that is traditionally focused on applications, 10:56.040 --> 10:59.040 so it doesn't have any kernel, it doesn't have system D, 10:59.040 --> 11:03.040 it doesn't have any of the system tooling that we traditionally have on systems. 11:03.040 --> 11:06.040 And so you start from this image, you have system D, 11:06.040 --> 11:09.040 the kernel, a little bit of computer-fest tooling, 11:09.040 --> 11:12.040 based on an explicit, the things that you usually have. 11:13.040 --> 11:16.040 You compute the root-fest digest of everything 11:16.040 --> 11:18.040 that you have in your image of all the files, 11:18.040 --> 11:20.040 you compute essentially the whole tree, 11:20.040 --> 11:23.040 and you compute the hash of the root-fest image, 11:23.040 --> 11:27.040 and you inject that into the UPS. 11:27.040 --> 11:31.040 You also build the UKR, you take the kernel from the root-fest, 11:31.040 --> 11:33.040 you generate the EID, or you already have it, 11:33.040 --> 11:35.040 and you ingest the deposit hash. 11:35.040 --> 11:38.040 You create the UPR, you sign it for sick boot, 11:38.040 --> 11:40.040 and finally you add it to the container image. 11:40.040 --> 11:44.040 And that's how you can have everything into a single board, 11:44.040 --> 11:49.040 a single object that essentially is collection of files, 11:49.040 --> 11:54.040 but which can then be translated into this composites repository. 11:54.040 --> 11:57.040 So how do we do actually do that last part? 11:57.040 --> 12:03.040 How do we take a container image and make it work at an installed instance 12:03.040 --> 12:05.040 on the root-fest system? 12:05.040 --> 12:08.040 It's a project, so it's a site project, 12:08.040 --> 12:10.040 essentially to the composites project, 12:10.040 --> 12:12.040 which is written in Rust, 12:12.040 --> 12:14.040 and does all of this plumbing, 12:14.040 --> 12:17.040 and making sure that you can compute the root-fest digest 12:17.040 --> 12:19.040 from the container image, 12:19.040 --> 12:23.040 and can mount these files systems 12:23.040 --> 12:26.040 when you actually booting it up. 12:26.040 --> 12:29.040 So it has support for cooperating, 12:29.040 --> 12:31.040 so only your container image is, 12:31.040 --> 12:36.040 just what we did building a noise through a classic container build process, 12:36.040 --> 12:39.040 and completing that into actual root-fest system, 12:39.040 --> 12:42.040 and irrefest images, and that are a focal pose of this. 12:42.040 --> 12:45.040 We end all of the thing around asynchronous explanations, 12:45.040 --> 12:48.040 so if you use container images in the past, 12:48.040 --> 12:52.040 you know that essentially there's no asynchronous inside of a container, 12:52.040 --> 12:54.040 usually it's hidden, 12:54.040 --> 12:58.040 and so all of the asynchronous levels and everything, 12:58.040 --> 13:01.040 they are not really taken into account generally. 13:01.040 --> 13:05.040 So this project makes sure that the listening labels are correct, 13:05.040 --> 13:06.040 and everything. 13:06.040 --> 13:09.040 So this works based on a good book for any other tools 13:09.040 --> 13:11.040 that use special extended attributes, 13:11.040 --> 13:14.040 that are not really handled by containers right now. 13:14.040 --> 13:18.040 And it manages all of the boot resources 13:18.040 --> 13:20.040 unlaying using the boot loader specification. 13:20.040 --> 13:23.040 So right now, if you have your AI, you can directly drop them 13:23.040 --> 13:25.040 in the right places. 13:25.040 --> 13:27.040 And it does also the updates, 13:27.040 --> 13:31.040 and make sure that you can actually install updates. 13:31.040 --> 13:34.040 And so we can see this is working progress in a sense. 13:34.040 --> 13:36.040 We welcome contribution, of course. 13:36.040 --> 13:41.040 We'll see later where we want to take all of this. 13:41.040 --> 13:45.040 All right, so let's do a little demo of what this looks like 13:45.040 --> 13:48.040 on a final system, so. 13:48.040 --> 13:51.040 Okay, let's work. 13:51.040 --> 13:52.040 All right. 13:52.040 --> 13:55.040 So here we're building a system that has been built 13:55.040 --> 13:57.040 with all of this tuning. 13:57.040 --> 14:00.040 So it was system DBT showing a first. 14:00.040 --> 14:06.040 All right, I'm learning as root. 14:06.040 --> 14:09.040 How it's variable enough? 14:09.040 --> 14:11.040 No, that did not help. 14:11.040 --> 14:14.040 Sorry, are we good? 14:14.040 --> 14:17.040 Okay, so we've got to build a name old 14:17.040 --> 14:19.040 and we loaded our own key. 14:19.040 --> 14:21.040 So we don't even need anything like here. 14:21.040 --> 14:23.040 We can't reset everything. 14:23.040 --> 14:26.040 So we loaded our own secret boot keys. 14:26.040 --> 14:29.040 And we put a boot CTL, you know that we're building a 14:29.040 --> 14:35.040 UKI and it's system DBT loading up our system. 14:35.040 --> 14:37.040 All right, so we're then going to take a look 14:37.040 --> 14:41.040 at actually what this looks like like on the disk. 14:41.040 --> 14:44.040 So if we take a look at slash boot, we have, 14:44.040 --> 14:46.040 here essentially, it's like it's a fake. 14:46.040 --> 14:48.040 In a sense, it's the ESP. 14:48.040 --> 14:52.040 So we have the UFI directory, all the UKI, etc. 14:52.040 --> 14:55.040 And in the end, we only have two partition. 14:55.040 --> 14:58.040 We have the ESP and the root disk, 14:58.040 --> 15:01.040 multi-sciss route, where we have all the composites stuff. 15:01.040 --> 15:03.040 So if we look at the slash boot point, 15:03.040 --> 15:06.040 it's another layman's point because it's composites. 15:06.040 --> 15:08.040 It's a composition of different things. 15:08.040 --> 15:10.040 If you look at the kernel common line, 15:10.040 --> 15:12.040 you have the composites hash. 15:12.040 --> 15:14.040 And if we go into c-stoot, 15:14.040 --> 15:16.040 she's kind of like the rule, rule, the rule, 15:16.040 --> 15:17.040 the partition. 15:17.040 --> 15:19.040 You have the composites directory. 15:19.040 --> 15:21.040 Inside, you have both the objects, 15:21.040 --> 15:24.040 which are like all the files and the image, 15:24.040 --> 15:28.040 which is the interface image that is used by composites. 15:28.040 --> 15:32.040 So if you measure the FSVD hash of this file, 15:32.040 --> 15:34.040 it's the one it's stored under. 15:34.040 --> 15:36.040 So like we know that it's the right one. 15:36.040 --> 15:38.040 And if you look at the objects on the system, 15:38.040 --> 15:41.040 then you have essentially all the files of your root partition 15:41.040 --> 15:44.040 that are stored there, 15:44.040 --> 15:48.040 hashed under the FSVD digest. 15:48.040 --> 15:53.040 Then if we take a look at the error-facimage, 15:53.040 --> 15:54.040 the composites image, 15:54.040 --> 15:57.040 and we take a look at the specific file inside of it. 15:57.040 --> 16:00.040 So here, pick the time zone for bristle. 16:00.040 --> 16:04.040 And we can find out like it's the first video. 16:04.040 --> 16:06.040 FSVD hash under which it's stored. 16:06.040 --> 16:09.040 So if I reboot the file from the object store, 16:09.040 --> 16:12.040 I replace it with the focus content. 16:13.040 --> 16:15.040 And then I take a look at it. 16:15.040 --> 16:18.040 Then I do get the file, which is okay. 16:18.040 --> 16:19.040 No problem here. 16:19.040 --> 16:21.040 But if I take a look at it's rule, 16:21.040 --> 16:24.040 like where it's actually mounted on the root file system, 16:24.040 --> 16:26.040 then the kernel will tell me, 16:26.040 --> 16:28.040 no, that's not going to happen. 16:28.040 --> 16:30.040 First of all, I just bought the file. 16:30.040 --> 16:32.040 There's no FSVD digest on it. 16:32.040 --> 16:35.040 So it refuses to open the file. 16:35.040 --> 16:38.040 And then even if I enable FSVD, 16:38.040 --> 16:41.040 then it obviously has a different FSVD hash, 16:41.040 --> 16:44.040 and one, it should be having as part of the image. 16:44.040 --> 16:48.040 And so the kernel is still refusing me from opening it. 16:54.040 --> 16:55.040 All right. 16:55.040 --> 16:58.040 So where do we go from here? 16:58.040 --> 17:00.040 So we have a few plans. 17:00.040 --> 17:04.040 If you remember, if you've seen or put a demo presentation 17:04.040 --> 17:09.040 at all systems go, essentially it was vision zero. 17:09.040 --> 17:11.040 This is like the evolution of this. 17:11.040 --> 17:15.040 When we said at the time that the future plans were there, 17:15.040 --> 17:17.040 well, we've made the future plans, 17:17.040 --> 17:19.040 and now we have further future plans. 17:19.040 --> 17:22.040 And the idea here is we, 17:22.040 --> 17:24.040 the computer first project needs self. 17:24.040 --> 17:26.040 It's mostly distribution access nature. 17:26.040 --> 17:28.040 You can pick almost a distribution. 17:28.040 --> 17:30.040 Right now we have integration forward, 17:30.040 --> 17:31.040 drag it and you need audio, 17:31.040 --> 17:34.040 but you could make it for other tools. 17:34.040 --> 17:37.040 And we want to integrate that with BTC, 17:37.040 --> 17:41.040 which also has kind of a goal of being 17:41.040 --> 17:43.040 as much as possible distribution agnostic. 17:43.040 --> 17:45.040 And the BTC project, 17:45.040 --> 17:47.040 it's the bootball container project, 17:47.040 --> 17:50.040 we're trying to make those images 17:50.040 --> 17:51.040 where we take a container, 17:51.040 --> 17:53.040 and make it the transport format, 17:53.040 --> 17:56.040 do format for building images for systems 17:56.040 --> 17:59.040 and distributing them to systems. 17:59.040 --> 18:02.040 Ideally, we would move also, 18:02.040 --> 18:06.040 that to that kind of format for other methods, 18:06.040 --> 18:10.040 all the system that are used is always read right now. 18:10.040 --> 18:12.040 So we have the flat packs, 18:12.040 --> 18:15.040 and that are heavy users of always read. 18:15.040 --> 18:18.040 That could potentially use composite files as well. 18:18.040 --> 18:22.040 And ideally, we also could use it for container images. 18:22.040 --> 18:25.040 So if you imagine a system where you would have both 18:25.040 --> 18:28.040 the container images and the system, 18:28.040 --> 18:31.040 the root partition inside of the same composite first tool, 18:31.040 --> 18:34.040 you would get very interesting properties 18:34.040 --> 18:36.040 around dedification and memory users. 18:36.040 --> 18:38.040 So like if you had, for example, the GDPC, 18:38.040 --> 18:41.040 that would be coming from a container or from the system, 18:41.040 --> 18:45.040 you would have the same file stored in the composite first repository. 18:45.040 --> 18:47.040 And as the same file is the same, 18:47.040 --> 18:49.040 I know it would be the same file in memory, 18:49.040 --> 18:51.040 in the cache, in the kernel cache. 18:51.040 --> 18:54.040 So if you had multiple containers coming from different places, 18:54.040 --> 18:55.040 different base images, 18:55.040 --> 18:59.040 but still using the same GDPC would still get one copy in memory. 18:59.040 --> 19:01.040 So it's really interesting, 19:01.040 --> 19:05.040 in terms of usage, memory, and disc usage. 19:05.040 --> 19:07.040 Finally, the composite first and GDPC project 19:07.040 --> 19:11.040 have been accepted as sandbox project in the cloud 19:11.040 --> 19:13.040 net impeding foundation. 19:13.040 --> 19:16.040 And so we happy that we can move forward with that. 19:16.040 --> 19:18.040 Here are the link to the repose. 19:18.040 --> 19:20.040 If you want to check this project out, 19:20.040 --> 19:22.040 and we're happy to take questions. 19:22.040 --> 19:23.040 Thank you very much. 19:24.040 --> 19:26.040 Thank you. 19:43.040 --> 19:46.040 The question was if you can go directly from a tar file 19:46.040 --> 19:48.040 instead of from an OCI image. 19:48.040 --> 19:51.040 And yes, I think you can. 19:51.040 --> 19:53.040 I haven't tested that in a long time, 19:53.040 --> 19:54.040 but I think that was one of the first things 19:54.040 --> 19:57.040 that I implemented as a way of getting to OCI images. 19:57.040 --> 19:59.040 I think there's a comment for that. 20:17.040 --> 20:19.040 Yeah, I'm really happy you got that question, 20:19.040 --> 20:22.040 because we had a slide about that, and we took it out for a time. 20:22.040 --> 20:25.040 Yeah, so the key thing here is, 20:25.040 --> 20:27.040 yeah, so basically the question is, 20:27.040 --> 20:29.040 instead of having like the partitioning base, 20:29.040 --> 20:33.040 the invariant layout, what do we bring to the table here? 20:33.040 --> 20:35.040 And yeah, the benefit here, I think, 20:35.040 --> 20:38.040 is that because you have this one file system, 20:38.040 --> 20:40.040 like with these sort of partitioning base layouts, 20:40.040 --> 20:41.040 you have your A partition, 20:41.040 --> 20:43.040 and then the Verity partition for that, your B partition, 20:43.040 --> 20:46.040 and then you have your multiple state partitions. 20:46.040 --> 20:48.040 You have to make a lot of decisions and advance about that, right? 20:48.040 --> 20:52.040 Like you have to say, okay, this is how big I ever believe any image I produce 20:52.040 --> 20:55.040 will ever be, and hopefully you never go over that, right? 20:55.040 --> 20:58.040 Because it's really difficult to change the size of that partition 20:58.040 --> 21:00.040 without doing a complete system reset. 21:00.040 --> 21:06.040 And for example, if you ever wanted to do more than one rollback, 21:06.040 --> 21:09.040 then you would be in a situation where you can't pin anything 21:09.040 --> 21:11.040 except one version. 21:11.040 --> 21:14.040 So I think that those sort of sticking points, 21:14.040 --> 21:16.040 and then another big use case we have, 21:16.040 --> 21:18.040 especially is that we want people to be able to do, 21:18.040 --> 21:20.040 just like with RPMOS, 21:20.040 --> 21:23.040 you can overlay extra packages if you want the mind your system. 21:23.040 --> 21:25.040 That's going to be a big use case for that, 21:25.040 --> 21:27.040 and that really feeds into the, 21:27.040 --> 21:29.040 we have no idea how big this partition's going to get. 21:29.040 --> 21:31.040 So having a single partitioning layout, 21:31.040 --> 21:34.040 where you can sort of dynamically have as many images you want, 21:34.040 --> 21:35.040 and they can be as big, 21:35.040 --> 21:37.040 and also deduplicated on the disk. 21:37.040 --> 21:38.040 I think that's a substantial advantage, 21:38.040 --> 21:41.040 especially for the situations we plan to use this for. 21:47.040 --> 21:50.040 I think that's a good question. 21:50.040 --> 21:52.040 I think that's a good question. 21:52.040 --> 21:56.040 Do you have the integrity of this stack up position? 21:58.040 --> 22:01.040 Oh, look, more of the slides that we take over time. 22:01.040 --> 22:02.040 These are very good questions. 22:02.040 --> 22:06.040 The question was, should we use like DM Crypt in DM Integrity 22:06.040 --> 22:09.040 for this one big partition we have? 22:09.040 --> 22:11.040 And yeah, okay. 22:11.040 --> 22:14.040 So there's this sort of famous problem in the kernel. 22:14.040 --> 22:18.040 You know, the file systems they were written in like, you know, simpler times. 22:18.040 --> 22:22.040 And we didn't expect that they would have to be robust against evil 22:22.040 --> 22:24.040 maids or evil disk firmware or whatever. 22:24.040 --> 22:27.040 And you get file system, maintainer, 22:27.040 --> 22:28.040 selling is all the time. 22:28.040 --> 22:31.040 Look, you can't like expose a file system to entrusted content 22:31.040 --> 22:33.040 because you could basically like tune the kernel. 22:33.040 --> 22:36.040 And yeah, this is kind of an issue with our approach 22:36.040 --> 22:39.040 because if you just have a file system, 22:39.040 --> 22:41.040 and you don't verify that, 22:41.040 --> 22:43.040 and then you let the file system code out it, 22:44.040 --> 22:46.040 maybe there's some problems in there. 22:46.040 --> 22:47.040 So one way of working around that 22:47.040 --> 22:50.040 would be using DM Crypt in DM Integrity. 22:50.040 --> 22:53.040 Yeah, we have different ideas for how that could also go. 22:56.040 --> 22:58.040 Yeah, do you just do that on this one? 22:58.040 --> 23:01.040 Essentially, the idea is that, yes, it is weaker, 23:01.040 --> 23:05.040 but in most cases, you're going to have to open a state partition 23:05.040 --> 23:06.040 somewhere. 23:06.040 --> 23:08.040 So unless your system is fully stateless, 23:08.040 --> 23:11.040 or it doesn't use partition on disk, 23:11.040 --> 23:14.040 then you're going to have to open a looks-incredited partition at some point. 23:14.040 --> 23:17.040 And if you've got a vulnerability that is capable, 23:17.040 --> 23:21.040 or an attacker that is going to inject code into a looks-incredited partition, 23:21.040 --> 23:23.040 it's going to get it anyway. 23:23.040 --> 23:28.040 So the main downside of this is that we cannot just wipe 23:28.040 --> 23:35.040 one partition to refactor or to do a factory reset on a system. 23:35.040 --> 23:39.040 So you can attress that if you think a system has been compromised, 23:39.040 --> 23:41.040 you can attress mostly anything on it. 23:41.040 --> 23:45.040 You have to fully re-install it. 23:45.040 --> 23:48.040 Let's see if you have a slide for this one. 23:48.040 --> 23:54.040 So your security module, he's on the current command line, 23:54.040 --> 23:58.040 hash being the point of trust, where you stop the trust. 23:58.040 --> 24:01.040 What component uses that hash? 24:01.040 --> 24:04.040 Is that the kernel, or is that the user space box? 24:05.040 --> 24:08.040 So basically inside the init RAMFS, 24:08.040 --> 24:12.040 we have a pivot, composed of S pivot, something I forget exactly what it's called. 24:12.040 --> 24:16.040 And it's responsible for the question is what part is the kernel command line 24:16.040 --> 24:19.040 to get the compose of S hash and enforces that? 24:19.040 --> 24:22.040 And that's part of the init RAMFS, so that's also signed. 24:22.040 --> 24:27.040 And it reads the proc command line, it loads that up, 24:27.040 --> 24:30.040 it looks in the root file system, it opens that file, 24:30.040 --> 24:32.040 measures the FSVity of that file. 24:32.040 --> 24:35.040 It confirms that it's exactly equal to what was in the kernel command line 24:35.040 --> 24:37.040 and only then does it proceed. 24:37.040 --> 24:41.040 So if I'm running out runtime and I have the same privilege 24:41.040 --> 24:46.040 in the food OS, and I over mount your whatever process 24:46.040 --> 24:48.040 when you have what happens then. 24:48.040 --> 24:50.040 Yeah, then you can do that. 24:50.040 --> 24:54.040 Yeah, if you want to mount something on top of the root file system, 24:54.040 --> 24:56.040 then yes, you can do that. 24:56.040 --> 25:00.040 You can't, because the signature is the effect of the kernel all the time. 25:00.040 --> 25:01.040 Not just in EW. 25:01.040 --> 25:05.040 Yeah, but yeah. 25:05.040 --> 25:08.040 There's still a lot of things you can do in that scenario 25:08.040 --> 25:12.040 to make things look different and you would think that they are. 25:12.040 --> 25:15.040 If you know a time store, good thing to see you.