 OK, I guess it's time to start. This works, right? OK. Hi, I'm Lena Padling, and I'm going to talk about systemD and TPM2 today. Yeah, let's jump right in. So with the stuff that I'm going to talk about, like I want to start out with making clear what the actual goals are with TPM2 support in systemD. I probably want to sketch up with other OSes, because usually all the other commercial, the big OSes, generally default to using some form of Secchia enclave TPM by default. Generic Linux typically doesn't. I mean, there are some Linux-based operating systems, which do, of course, but it's usually very focused and not available in generic stuff. And if people want to do their own OS like that, they have to do major work. And I want to make that a lot easier so that this kind of stuff is just available without much effort. And people don't really have to think so much about it. So yeah, the goal is to default to a measured boot and using that for unlocking distance things. I want to go further than just disk encryption. I want to be able to unlock any former secret that we have to TPM and make that a natural way how you interface with services. There is a goal of secure parameterization. I mean, this is kind of related to what I was just asking Serge about earlier. Yeah, sometimes it's important to be able to parameterize the West when you boot it. And that's a difficult problem because you want to really restrict what you can do there. Contradan computing. In focus, they have different requirements. Ideally, we would make this as little different as possible. So yeah. And of course, one of the purposes is also to open up the TPM for other purposes than what we in the system you want to use it for, so that it generally just works. And there are some semantics on how it's initialized and things like that. Yeah, so the goal really is to be ultimately good enough that we can turn on TPM to support by default on generic Linux and not just as an afterthought. So let's talk about the current state of what system you can provide with the US right now. So basically, I'm just going through the different components in system you that have TPM hookup in one form or another. The first one is, I guess, the most interesting one, which is the FTE support, like the full disk encryption by a system decrypt setup. System decrypt setup is basically just a wrapper around lip-crypt setup. But what it does do, it integrates it with the rest of the system, like with the system you boot process, for example, with interactivity, but also with all kinds of crypto stuff, including FIDO2 and PKCS11, and what we like the most interesting thing here is which is TPM. So yeah, the obvious way is to unlock the Lux volumes by TPM2. We do it a little bit different than the previous solutions because we actually extend the Lux superblock with our data, so it feels a lot more natural because you don't have to have secondary data anywhere else. You don't have to store anything in NV indexes or something like that. It's entirely like all information that is needed including the Lux superblocks and nowhere else. So that's kind of nice. The relevant TPM policies that we actually implement are one based around literal PCR values. I'm not sure how useful this is because it's so nasty dealing with literal PCR values. More interesting is the one of the signature of PCR values, like the extended authentication thing that was mentioned in the earlier talk. And the third one is pin based. That is then interactive during boot. Or you can have a combination of these. This assessment crypt setup is not just about unlocking things, it will also, if you want to, one thing more, which is unlock the, oh this is annoying, the volume key that just unlocked to PCR 15. The purpose of this is that we want PCR, I will talk about this more a little bit later, but the goal of this is basically that we have PCR 15 as a way. Like it's a hash that represents the identity of the system, if you so will. And if you bind TPM objects to that, the idea is that this basically means that only that specific machine can unlock it and not other machines. Then another tool that's closely related to system decrypt setup is called system decrypt enroll. As the name suggests, it does the other thing. It actually enrolls a TPM on a looks partition. It's not much more to say, I mean, you can also enroll a couple of other things like recovery keys, which are probably actually useful in the context of TPM so that if you have some way to get back into the machine, if TPM stuff didn't work. Let's talk about the next component, system DPCR phase. This is about measurement now. It's not about unlocking. It's more about getting the PCRs in the right state. One component, system DPCR phase, the job, what it does actually, it's invoked at selected places of the boot process and measures certain words into PCR, which one was it, 11. So the relevant words are like, when system D first takes over from the kernel, it measures the word enter entity into that and then when it's done with the enter entity, it measures the word leave in it already and so on and so on and then it's assisted in it and ready basically when the boot up is finished. Why is that useful? This is useful if you bind secrets to the value of PCR or to a signature of a value of PCR 11, then you can use this to make secrets that only can be unlocked in a certain part of the boot or in multiple parts of the boot, but not any later. This is at the most basic, even if you don't care so much about the phases, what's kind of useful is by the way that even if you want your keys to be unlockable during the entire boot time, at the very least you can say then yeah, not on anymore and when the system shut down. So that's one thing that we do. Yeah, so it's really about, I mean some operating system that has a concept of destroying the PCR management and measuring values by measuring garbage into it or something like this. This is really supposed to be more useful that you can actually pinpoint exactly where a key shall be unlockable and where it shall not. There's something very closely related which is the new PCR machine. It measures the machine ID, which is basically just a file and it's a machine ID which contains something like a UAD into PCR 15. I mentioned earlier already, right? Like this was where the volume, root volume key of Lux is also measured into. Background is the same thing. We want PCR 15 to be a PCR that identifies the system. Now, the system of course needs to be somewhat generic, right? Like it's not specific to one use case, it's supposed to be generic for everybody. So if people do not actually use disk encryption or something, then this is supposed to help them to have an identity anyway, right? Like of course, much weaker properties but that's not really our problem. Anyway, so yeah, PCR 15 contains both the root volume key and the machine ID. First the volume key and then watch later when we actually have access to that machine ID, the machine ID. And there are system new PCR FS also measures into PCR 15 and what it measures is actually the file system UUID and type of like this can actually be instantiated multiple times. So if you have multiple file systems, the idea basically is that yeah, once all three of those things ran like the system decrypt setup stuff that matters the volume key, system new PCR machine which basically measures the machine ID and that system new PCR FS which measures a couple of file system. PCR 15 is basically done and it can be useful to identify the machine in that combination that it was put together. So that it's definitely gonna change if you like install it in any different way. These things are enabled by default but only under the condition that you're actually booting with a UKI kernel. The reason like we would like to, I mean we would have liked to enable this by default in any case but I mean we take possession of PCR 15 was this right where we consider it our own private property once this is enabled. So we wanted a way how people can actually explicitly tell us we buy into our view of the world and that's like yeah, we decided that yeah, if we detect that the system is Buddha with UKI we do this by default. Of course by default doesn't mean that you couldn't turn it off. Yeah, the goal of the PCR 15 management is identity of the local system. Next thing is the system destub was mentioned earlier in the earlier talk because it was forked already. System destub is a EFI stub glued in front of the Linux kernel runs in UFI mode there's various things most of them are not really relevant in this context but one thing it actually does that is relevant in this context is TPM measurement of the components of the UKI. The idea basically is this is also done into PCR 11 I probably should have mentioned this here. So basically the idea is that if you pick a different kernel PCR 11 as contains the identity of the kernel PCR 11 is assumed to be zero when this stuff initialized. So this way PCR 11 is first becomes an identifier of the kernel booted along with it's inner dirty and all the other components. And if you remember correctly the PCR phase stuff is also measured into PCR 11. So yeah it encodes both the things which was you picked and which phase of the boot you're in. Yeah, this was mentioned in the earlier talk kernel system destub already we call that the UKI. Oh, I actually did mention the PCR 11 thing. So anyway, yeah, so it matters into PCR 11. It also matters they use kernel command line into PCR 12. So the parameterization of the system. To summarize this these are the relevant PCRs that system deep kind of takes over if you buy into the model and use SD stub as the UKI stub. So first of all PCR 11 contains the measurement of the components of UKI and the boot phases PCR 15 the system identity and PCR 12 12 the kernel command line. So it's about basically the first thing picks boot phase and OS the second one system identity and that is kind of powerful that you can then build complex policies out of this for your boot TPM objects of your choice. So next one is system in measure. Actually, I mean it sounds like it would actually measure something but what it actually does it predicts what the PCR values will be in PCR 11 given a specific kernel that is booted and given a specific boot phase is like the systems currently in specific boot phase. What's the purpose of this? It's basically that you can build your policies and log arbitrary objects to this. It can not only pre-calculate the PCR values it can also sign this stuff for you. So yeah, it did currently only focus on PCR 11. We want to extend this by the way that it can also predict the PCR values you will see in PCR 15 and PCR 12 depending on your configuration so that you can do this ahead of time. This is systematically different like by the way how grub boots generally work because they put everything in the same PCR which is great if you are just interested in logs but it's terrible if you want to predict anything and bind security to this with system in measure our goal really is about like having predictable ways so that's why we separate out the PCRs and the purposes of this. Yeah, you can use system in measure to sign the expected values right away and system decrypt setup can actually use that information for the signature based policies that I mentioned. And there's another tool called Ukify I'm not entirely sure yet how we want to pronounce that if it's Ukify or Ukify or Ukify, I don't know. Anyway, this little tool helps you building UKIs so what it actually does, it takes the kernel image takes the system destub, takes an inner ID, takes device tree, whatever else you want, boot splash and so on and a private key glues them all together and a PE image signs them with secure boot, use the private key for that. It then also does the, like it invokes system to measure to predict what the PCR 11 value will be once the system is booted up. We'll sign that with another signature key and we'll then also add the signature to the kernel as well so that the kernel when it boots up we know what the PCR value is going to be and the kernel already ships with the signatures that matches the expected PCR value so that when the system decrypts it up runs it can just take the signatures that was passed that was part of the kernel and unlock the disk with it. So that result is basically that you can say, yeah, I lock my disk against Fedora kernels and then you have to boot a Fedora kernel to actually unlock the disk and you never have to re-enroll anything. Next topic is system decredentials. System decredentials is not just about TPM, it's basically our way how you can pass little secrets, certificates, private keys, but also configuration if you want into a system D as a whole and into services specifically and there's a way how you can propagate them, you can inherit them down from the system into a specific services. System decredentials are actually powerful concept that people should really start using because you can also pass them in from a hypervisor, container manager into the system and then from system D into the services and then you can pass them on further down to container manager and to another VM and so on and so on. System decredentials are very easy for applications to read because it's just ultimately they see it as a directory where these files end up in but they also have, I mean here, just to mention this, like you can supply them to the system by SM bias and QMF, WCFG and a couple of other things, but the one thing that is interesting in this context is that they can also be locked to the TPM with a symmetric key. The reason why we originally added this is secure parameterization of EFI, like of UK eyes in a second world because this allow listing thing that was discussed earlier is one way out of this, but sometimes it's like you want to parameterize in more complex ways and keep the stuff secret, right? And so yeah, if you put this information in the ESP which is unprotected, you need to protect it somehow so our solution out of this was this. It's actually extremely simple to use, you just say, there's a tool called system decreds and we just say, I have this little bit of information, you can use it like in a shell, like in a piping thing and then it does everything automatically for you so that people don't even have to think in any way about TPMs or anything like this. Unable to mend similar TPM policies as crypto setup was the exception of the PIN because it's inherently non-interactive, right? Like the goal of this TPM hookup is that it happens at the latest possible time when it's actually needed, the decryption and authentication of the data and that happens basically when we start a service. But that also means it can't really be interactive because of course, yeah, you don't want to boot up the system interactively, presumably. I mentioned this already, system decreds is a tool, how you can actually create these things. All of system Ds, various components can nowadays deal with system decredentials. It's actually kind of nice because you can securely supply SSH keys and things like that through this and yeah. To be more specific in unit files and system Ds service files you can use set credential load credentials and set credential encrypted to set these credentials and it just does the TPM stuff behind your back. You don't really have to care about that. Yeah, use case for the credential stuff secure parameterization of systems and services can be replacement for things like cloud ends and clouds and yeah, OS installs can parameterize you guys. It can already have said all that. Next thing is system D report. System D report is a, I guess like a declarative repetitioning tool that can run at boot and add petitions that otherwise are not there. Why is this relevant in the TPM context? That's because it can create petitions and automatically encrypt them and link them to the local TPM and roll them there. The use case for this is basically that you ship an OS as a variety image, basically justice slash user petition and then on first boot a root file system is dynamically created. The user thing is, the user petition is basically mounted into it and the system boots up and in that case this has a major benefit that the root file system is inherently local and all the secrets to unlock it remain inherently local between the TPM and the host. So you do not ever have to provision any of the secrets that are generated locally and it's also kind of nice because it adapts to local sector sizes, local disk sizes and things like that. So yeah, declarative non-destructive automatic petition tool, non-destructive basically means you can't really do anything bad with it. It's the only thing that you can do with it is growing petitions and adding petitions. That's really it. Yeah, the key really is that the main point is that all the key material to lock down such petitions is generated locally and locked to the TPM. Yeah, the use case I can already describe. So this was the trying to give an overview like what we currently have. This has holes everywhere and this is like the holes is what the rest of the talk is going to be about and maybe it makes sense like if anyone has a question right now, we can answer that. Otherwise, I would just continue with all the shortcomings and all the white space that still needs to be filled in to actually build a proper secure system. Is there anyone, no one has a question? Was my talk that good or? Everybody's just confused. Anyway, so let's talk about the shortcomings because there are many of those. I mean, by the way, I'm not a cryptographer. I'm not a TPM guy. I'm struggling reading all the TPM specifications like everybody else. I try to talk to the right people though and figure out what to distill out of them, what actually makes sense in the general case. I also talk to the Windows people, by the way. I work for Microsoft in case this wasn't clear. What they're actually doing, they do different things, by the way. Like for example, this is mostly for historical reasons I guess because when they designed the TPM stuff and when it was still TPM 1.2 was a thing and you didn't have what's EAs, enhanced authentication stuff. So you couldn't sign PCR values and things like that. And that of course forces them into certain other ways, like massively other ways. And we have the luxury of coming late in this way so that we can rely on signing PCR values and don't really have to do really, really messy stuff. But anyway, it's very difficult from all the people who do think this TPM distilling what we actually want in the general case and the generic case because that's what I care about in the system. I don't care so much about specific solutions for specific projects or something. I want the general stuff that works for, maybe not for all, but for a large part of the community. Anyway, let's talk about the shortcomings. One of the major things is that we took possession of PCR 11, 12, and 15 for the purposes that I just described, but, and we know that there's zero initially, at least if you boot a regular Shem style boot, but precisely that's a problem because there's zero, any other user space can, like any other learners can basically boot up and they're also zero and they can measure the exact same stuff into it that we do without actually just making it up basically and could unlock secrets with that. So to lock this down we probably would have that Shem probably should measure like something identifying the payload it's about to start doing boot up into all the PCRs that otherwise aren't used. The effect of that would basically be that if you use a different, like if you boot a different OS, you can be sure that the PCRs will be different and that would be lock this thing down. This is a major security hole I guess in a way. It goes away if you don't care about Shem and just enroll everything into the UFI chain directly, the key ring, the DB and things like that, but as long as people want to use Shem we probably should address that. It's a big one I think. The other one is we currently don't keep a measurement lock. I mean we do log everything even in structured form to the journal like to this lock, but there is like I mean for the stuff that happens during UFI like all the measurements there's the UFI measurement lock so you can actually argue about what happens. So far we don't have anything comparable to that. We get away with this because like for us everything's predictable and our goal is not so much about like arguing about what happened but more about unlocking secrets and hence predicting of what's going to happen. But we probably should address that. I think sooner or later we probably want to implement something like the TCG canonical event lock format which is like the spec from TCG. But I'm not sure how much of the community actually bought into this so far. Like if there is actually a tool set that people actually use to parse this. As I understand the event lock format is actually pretty close to what UFI uses and it's just an extension for user space for this but anyway maybe I figure we should do that so that people can actually come at arbitrary times and argue about what's actually happened there. Another short come is asymmetric unlocking. Right now like it's always modeled that you enroll locally and you unlock locally but for various use cases that's probably not what you want but instead you want to encrypt it on one machine and then unlock it on another. For that asymmetric unlocking would be useful. There's actually a patch now that does this. It's work in progress but hopefully we'll have that. Yeah, the goal would then ultimately be that some orchestrator can prepare images for one specific host. Only that host can unlock it because it's the only one knowing the private key to it and that enables a lot of things. It's like the confidential computing people want this kind of model because they then can precede the TPM, the virtual TPM they give to the confidential computing stuff and then can be sure that only the VM can unlock it. Another issue is robot protection. I think this was also measured and mentioned in the earlier talk. Like this stuff allows you to bind a full description and encryption of credentials to like the vendor of a series of UKIs but there's no protection against taking a really old kernel that happens. Like for example, if Fedora would start signing UKIs with the Fedora key, there's nothing stopping you from using the UKI from 10 years ago and trying to unlock even if it's entirely insecure. So we need to look into that. I have some ideas about how this will work with NV indexes and things but this hasn't happened yet but it's definitely something we absolutely should do. Yeah. The next one is, what happened here? This one's a biggie. So for what I've just described so far it works really nicely if you have a specific system like for example a VM because that's a very controlled environment and you can enroll all the second boot keys to natively directly into the UFI curing, everything's great. The problem is once people want to do things on general PCs, things become much more complex because suddenly things are not closely defined anymore but people can extend their systems with boot ROMs and whatnot and firmware updates and everything else which makes it really hard to bind policy to because half of these, because they always are reflected PCR changes and there is no signature scheme for that. So what Windows for example does, it binds it to, it's like a bit locker to the literal PCR values and then tries to predict when they're going to change. They cannot predict everything because some of the changes just happen behind the back so they have also a way how they can turn off basically the binding to that. I'd rather not, yeah this is messy because on current PC systems there's simply no way how to make this beautiful. You have to deal with the fact that there's no signature scheme available, you have to work against that. Yeah the way I think we should address this like we have to address this sooner or later if this truly should become generic and people don't really have to think about this. The way I want this to work sooner or later is yeah, if we expect, I don't really wanna go into that game of predicting what the PCR values are going to be because that basically means you have to parse through the UFI measurement log and then figure out which are going to be the parts of it that are going to be replaced by a firmware update or boot loader update and then putting the new stuff in there and calculating every single thing. This sounds so terribly fragile and I'm, you know, if awareness people can do this I'm not sure if I want to maintain anything, like this sounds terribly fragile to me in particularly as it's never gonna solve the whole problem because some things they simply cannot predict and then they turn off the protection anyway. So I want to come to a way how we can basically bind a full disencryption or whatever you want to bind to. Some public key where the private key is actually stored in the TPM locally and then I'm kind of trying to come up with a scheme where we can then for one boot only basically generate like sign a different EA policy that is loser but only applies on the next boot and then for the subsequent boot doesn't work anymore. So basically that you have a system where you can basically say okay for the next boot I'm gonna turn off the PCR zero to four and seven binding and then you reboot and then we immediately bump the counter or something that protects all this to be disabled again and before that we looked at what the actual PCR values are and those are the ones that we bind to. I'm not sure like this is very vague. It's not surprising it's vague because the stuff doesn't exist. I just have ideas and we actually have to implement them first but I think this is a really nasty problem and I'm not aware of anything and then the Linux world would even remotely try to address this for the general case. Last missing feature which is like really complex one I didn't know what any of this means in the context of KX or user space reboot. Well let's say like I mean yeah I think I know what the right approach to that is right like because some people say yeah just don't measure anything more on the second KX or something sounds like chickening out to me you know the clouds they love KX like because of gray out time so I think we have to do something about this. My current thinking is probably we just want to continue measuring stuff as we always did. However we probably should add away how selected secrets that actually need to be handed over or handed over by some path tied to the TPM expecting what the VCR values are going to be after the KX and then be unlocked there. So basically what I'm saying is that I think it needs to be a different way how we pass over the secrets and not be enrolled in the super blocks of locks for example but anyway this is, I don't know if anyone has a clear idea what we actually should be doing in case of KX and user space reboot. I'm all ears but this is like yeah we really have to think about this because this is as it appears to me seems to be like very soon the common case how clouds reboot. So yeah, so much about the shortcomings I hope you can understand they are major and then particularly major if we think about PCs like actual random systems that people want to install systems on but if you have a non-PC like if you know your hardware and particularly if you run things in a VM I think it should already be pretty comprehensive and you can build things locked down. Any comments at this point? How much time do we actually still have like once now? Or I just only spoke half an hour or something. Anyone has a question? There's a question. Where the microphone. I have a comment. So in the missing feature F you probably also need to look at crash kernels and crash kernels. Well, I mean like if you have a crash kernel then everything's like you fucked anyway aren't you? Yeah, but you still need to be able to boot it. But yeah, I mean yeah definitely. But it sounds to me like it's like the 10 step and the nine before that are all missing. So we probably have to address those first. I don't like the crash kernel has magic powers about anyway, right? Like you can look into the first kernel, right? You might need to lock down what it writes in some way. Anyway, yeah, it's a mess. But I would rather not think about that yet. Let's first get the clean code pass in order and then we can think about what happens in the exceptional code path. But anything, any other questions? Somebody in front of that? Thank you. Yes, this can all be quite messy. One thing, so you have asymmetric encryption coming. Are there any other features on the horizon to support confidential computing that you're aware of? They're like, I'm actually in regular meetings with confidential computing people. I'm not one myself though. But they are trying to make it work and they have sending, like I think at least three PRs open that I still have to review. So yeah, there's a lot of stuff going on. But I mean, the confidential computing thing, like there are multiple different factions, like groups of people who have different goals with confidential computing, right? Like some of them want to run proper VMs with a virtualized TPM and things like that. That's probably very much in scope what we're doing, but then there's the other group of people who do confidential computing where they just basically run something like Qatar containers thing inside of them. Well, all of this is entirely irrelevant, but they still, it's not that binary. Nobody knows what's actually gonna happen, I don't know. But yes, there's lots of stuff coming going and for example, the measurement of the volume key, the measurement of the UIDs actually explicitly from request by Red Hat confidential computing people. So I don't know, yeah. We try to distill out of what they want when it's in focus for us. We definitely want to add this and yeah, there's some stuff pending. I'll take a look at the PRs. Yeah, well, review is always very welcome. Any other questions at this point? Can't believe that no one has any questions. I mean, I only have one slide left, so you really have to ask questions because otherwise I don't know what I'm gonna talk about. This is a bit different, I suppose, question. But what does Microsoft want in its system? Like, why do they care about system D since it doesn't run on their platform? Of course it does. It does? You know, I think we, how many Linux distributions do we have, James? We have, that is, public, Maranam, and we also have, internally we have any better operating system that's used for the infrastructure. There's more than that, right? Yeah. Anyway. But we also support, yeah, sorry about my one, Microsoft, come on. Yeah, so we also support all of the things used, but yeah, I don't want to get into marketing. How come? There's a lot of Linux users. So, I think it's public knowledge by now, like in Azure, like there is some component that runs Linux heavily and it's all system D stuff. It basically checks all the boxes of what system D offers. That's the reason why I work for them. But yeah, and there's multiple other projects that also do system D stuff. So, these are... Microsoft is a Linux company now. Any other questions? No, I can't believe it, like, come on. This is, like the shortcomings because it was supposed to be something that get you all started and give me ideas like how to address this stuff. But, okay, the only last thing that I have is something that... Can we have one more question? I'm sure. What are the changes for Linux distros to implement secure installation? Oh, wow, that's a good question. Yeah, that's good. So, like the first thing is probably to adopt UK eyes, right, like because UK eyes, like right now, like how classic this Linux distributions, regardless if it's Ubuntu or Fedora or Devian, how they boot is that they don't protect the NLRD. I mean, this was also on your slides before, right? And that's just a stupid idea, right? Like so, the first step is that they fix that whole. Various distributions are have gone past there, some are further ahead and others are not so far ahead. I know that the Arch Linux people have something that's pretty close to working and the Fedora people with the next release, they'll have it as an option that you can boot UK eyes and the confidential computing part in Fedora even has it already, like they actually go that way. If you have the UK eyes stuff, then this enables all the other stuff. There is no discussion yet. Like for example, I think that probably on TPM systems, the root file system by default should just always be locked to the TPM. And then if you want some other kind of locking as well, you probably should enroll something in addition to it, right? Or replacing it. But I think the default for modern operating systems at the most basic should be non-interactive TPM enrollment. But this discussion has not started yet because the way like reworking everything to be UK eye-based is just a massive effort because they currently, they have to rebuild everything because right now everything's built around like inner-degenerators that are inherently local to the system. And if they move this to pre-build them on central servers, on the build servers of the OS, it basically puts everything from the head on its feet and that's just, yeah. And so things happen bit by bit. That said, I know that the Arklinox people are way ahead and I'm doing things better there, but I'm not sure that I don't think they have anything on by default in this regard. But it's definitely my intention to do this, but I have no illusions this will take ages. And like Debian and these very conservative distros I don't think we'll see that in this decade or something. But I mean, in particularly a certain community still have this, I don't know, ideas about TPMs being evil, terrible Microsoft stuff that destroys open source or something and that's not gonna happen anytime soon, I guess. But yeah, it's definitely my interest though that general purpose distributions sooner or later switch to this and we're getting very positive feedback from some of them, at least. And particularly Fedora, Susie people do something there. Arklinox people do something there. Ubuntu people have for the embedded version of Ubuntu, whatever that was called, like Ubuntu core, do some things in this area, but I don't think they have switched to the system anyway of doing things. We'll see. Any other questions? Questions? That's a good question. Somebody was doing a question. Not a question, just a comment. I don't think you had mentioned it. For the Kexec issue, we've all had that thought too, of course, the only, I mean, we don't want to mess with the TPM at that point. So the only thought we've had is you take your credentials that you have at that point, your secrets, put them in a temporary, in it already, a one-time use in it already and pass that along to Kexec. I assume you've had that thought too, but. Yeah, but I mean, I'm kind of a believer that the secrets should better stay in the TPM as long as possible. It would be better, yeah. I'd rather have them pass them over in some TPM-locked form, that however is unlockable at the right point after the Kexec comes. And the question is simply, how do we define that? I'm pretty sure the PCR phase concept, like where we measure all these words into this, that probably might suffice because then you can basically, during shutdown, generate a new TPM, like encrypted container, that says, yeah, the words shutdown and final have to be measured and then the words for booting up of the next system have to be measured and then it can be unlocked until ready or something until the boot process is done or something like this. So I think we have things like that and we have to look into this, that this can just work. Yeah, I mean, so the point that I was making, trying to make earlier is I think we probably want to re-encrypt basically every time we are about to Kexec the data we actually want to path instead of having everything unlockable, not only during the first boot but also during late ones, if you follow what I mean. I think we should constantly only do it when we know that we're coming back because otherwise you basically unlock it for everybody always. So just thought maybe this is where you're going with that but I believe those PCRs, I think you can reset those. You can reset exactly two or something. Okay, yeah, it's been a couple of years so my memory could be fuzzy on this but I thought what are you using, 15, 11 and 12? Like we use, actually we use one more but I didn't want to go into detail but yeah, but there is one resettable. I mean, once they are resettable they kind of lose the magic properties that you can go back to. But here's what I'm getting at. I mean, if you want to treat Kexec at least from a TPM perspective similar to how you would if you were a cold boot, basically when the initial kernel or whatever kernel N is, you basically, like you said, when you get to that final, like the last thing it does before it unloads the TPM driver is it's going to reset those PCRs that you care about and then it basically is in the same state more or less that the system would be when it was warm booting and basically have that kernel act is whatever you're going to have your bootloader or the stub that's in the UKI basically have that then begin for the Kexec. But how do you protect the, that I mean, if you allow PCRs to be reset that way, relevant PCRs, like how do you protect that nobody else resets it for you? Well, but you listed that as another problem which you're going to have to solve, right? I mean, that was I think the first problem you mentioned. So I mean, you're going to have to come up with a solution for that anyway. And so if you solve that problem, then you should basically have it solved in this case as well. I, yeah, I mean, I come, it came to the conclusion that probably Kexec reboots are inherently different from the first one, right? Because the, you can pass information around and things like that. And we probably should take benefit of the fact that they are different and then have, like not try too hard to reset everything to the original way. There's benefits to be had, yes, agreed, but you don't have it working yet. So maybe, maybe, you know, start off with it. But saying it doesn't have to be different. I'm pretty sure that's exactly one PCR that you can reset, like the debug one or something. It's possible. Like I said, I could be mistaken, it's been a few years. So are you required to just do SRTM or would you consider like DRTM? So DRTM is what would give you PCRs that you can reset in a controlled way and then redo measurements in a controlled way. And so with the Kexec, you could basically reset it to a known good system. You run your DRTM code. You know that you're coming out of it in a known good state and you can verify those measurements and go forward. So I'm aware of DRTM, but it's hard enough to get this far, right? It's like the DRTM stuff as far as I know. It's like you still need special bootloader and everything, if I think like that. I think it's like, you know, I already list like six major issues that we have to address first. Once we come to that point, like the Kexec one is probably the least of the things that I want to actually address first. So yeah, but it's sure I have it somewhere in focus but also I, you know, I'm not a TPM guy or anything like this. It's not the world that I come from. I'm a user space, OS guy basically. So don't put too much pressure on me to just buy into all the newest fads that there are. But I'm pretty sure, yeah, I mean, if this stuff comes along and becomes usable and me as an idiot can make use of it, absolutely we should hook this up. But for now, I guess we probably should fix these problems first. I guess a matter of priorities. How much time do I still have left? Okay, very good. I mean, I only had one slide left but it's only the outlook thing which I wanted to show if I have nothing else to say. So that's good. So thank you very much. Thank you.