 I think that you've heard quite a bit this week about the integrity subsystem. In particular, you've been hearing about secure and trusted boot and attestation. And there were talks on, not necessarily the Linux integrity system, but about bootloaders in general. We had talks from AMD about this. We had talks on tools. We had discussions about routes of trust, as well as load time versus runtime verification, missing measurements, and so on. There was a lot about secure and trusted boot, and you're gonna see that this is not gonna be any different. There's more work going on in the Linux integrity subsystem on secure and trusted boot. So one of the things that you saw by Eric's talk and by Hiana, his talk, is that different people, different scenarios, have different policies. And from the very beginning, we defined IMA as being a system level policy that can be defined any way that anyone wants. You wanna do appraisal, you do appraisal, what you wanna appraise, how you wanna appraise, that's gonna be, that's up to you, what you wanna measure, how much you wanna measure. The more you measure, if you're using a TPM, well, the slower it's gonna be because it has to be sequentially extending the TPM. So it's up to you, and the decision is all yours as to what type of risks you're willing to take. Obviously, the less you measure, the more risk. The less that you verify, the more risks. And the more that you do, there's more performance impact. One of the things that on our way to upstreaming EVM was that we needed to be able to verify, this was before signatures and signature verification, we were using an HMAC, and we needed some way to have a master key to verify the EVM signature, to have a signature to create and update it. And so we upstreamed, trusted and encrypted keys, and as you saw from Matthew, they're using encrypted keys. And as you saw, heard from Matt, he's extended it to user space. So it's not only being used at this point for EVM, and there are new trusted key sources that are being proposed that are not TPM based. And those are being discussed as we go. There's some T based mechanisms for having a trusted key. Okay, so the remainder of the talk is gonna be what happened this year, what we've upstreamed, what's in the process of being upstreamed, and what's expected to come. So as you're gonna see, all of these things that have been upstreamed are basically for secure and trusted boot. The one exception is at the very bottom, and that's for StreetBug Ghost Crypto. So if we start at the work that's being done, I'm gonna call out Eric Richter, and my colleague who's been helping on this, and on doing the work that's involved in this for the secure and trusted boot for power, for open power to be specific. So one of the things that we're doing is that instead of modifying the Pixie boot loader, in Grub and in other boot loaders, you can do a remote boot. And instead of modifying the Pixie standard or other standards to support another piece of information, such as the signature, we decided to use appended signatures. And this code is now queued for the next, it's now, it's queued for the next open window. So you have appended signature support in addition to the extended attributes. And the firmware, the pre-boot keys that are needed, these are the keys that are now being loaded. This year we created a new key ring just for the purpose so that we can differentiate between the pre-boot and the kernel-based keys. And the pre-boot keys, the firmware keys, are being loaded into the platform key ring and are used only for verifying the Kexec kernel image. Initially it was for the security IMA extended attribute, but subsequently it's for the P cough signature and for the appended signature that we just spoke about. The other, when we initially started with IMA, we didn't wanna, we wanted it to be enabled by the distros without having a policy, without requiring a policy. And so when you boot IMA, you don't require a policy, but if you supply a policy, then it will enforce whatever that policy is. The problem was then for lockdown that you really needed to be able to say, yes, we're gonna enforce kernel modules, we're gonna enforce that the Kexec kernel image is gonna be signed. And so we really needed a build time option for that as well. And so we had the persistent compile build time option of specifying, of requiring that the Kexec kernel, Kexec module is images signed. And at runtime on open power, what we're working on is based on the secure boot modes of enabling a runtime policy. And Naina just posted this week, that policy, those patches. And we have from Microsoft, from this group, from Pricar, wherever you are, over there. We're measuring the boot command line, thank you. So, but in addition to measuring and having other methods of appraising files, we want those methods, the signatures that were used for verifying it to be included in the measurement list. And so you can't, so currently, the only you had one method of specifying what your template was gonna be. And with Matthew's help, we now have a runtime option for specifying the template. And as you see here, we can now, for the command line, specify the template as being imabuff, which would include the boot command line. And for the Kexec image, it would, there's a new format called imamodsec, that would include both the exatter extended attribute, if it existed, and also the appended signature. And similarly, you could do this for kernel modules. So, at this point, they're based on different use cases, different things come up. So, in the distro case, we had been told that the LSM policies, that policy rules wouldn't be deleted. That's not exactly true. And so, Yana helped us so that the policies, as the policies are being updated, the LSM policies are updated, the IMA policy will be updated as well to reflect the new numbers associated with the LSM. Thank you. And Stefan Berger, we were using the audit integrity rule for multiple things that has been split out now, so that the integrity rule is one thing, and the policy rules that you're loading will be a different audit message. And there were some problems with overlay FS, not all of it has been fixed, but at least for IMA, the extended attribute, it's now able to write out the extended attribute, read and write the extended attribute. So, we have a couple of new things, we closed a couple of new problems. The first one was, if you don't have an IMA policy, but you wanted to be able to prevent loading unsigned, the K exec kernel image or kernel modules or firmware, whatever that were unsigned, there was no way of doing it outside of IMA, and this is before the lockdown patches were upstreamed. So, with this new hook, it's possible. The lockdown patches are not using this, they could've, but they didn't. And we closed out a couple of the firmware issues that were still a problem, and we warned about others. If you don't have an IOMMU, then there's nothing much that you can do about firmware using DMA buffers. So, at least now we're warning that the DMA buffer, it's possible that a previously used buffer that the firmware could be used before the signature verification completed. And while they were working on overlay FS, they mentioned that there is now a concept of a persistent temporary file that, and those files, if it's persistent, well, it needs to be measured and appraised and everything else. And so we, you now have a new hook for doing that. And so for when you load, when you run an executable, the kernel takes care for you some locking issues, locking so that nobody can modify it while you're executing it. Unfortunately, that's not the case for M-MAP, this is nothing new, other people have known this, and there have been a couple of different methods for proposed LSMs as to how to lock this. For the time being, what was upstream was that at least if the file is open for write, we're not allowing, and you're verifying the signature on it, we're not allowing you to execute it. So, and so we, well, we added some Kexec self-tests that originally started out in the IMA as an IMA self-test, but was later moved into the Kexec. And those verify whether or not your system will tell you whether or not you're verifying the Kexec image or not. Based on policies. We have the IMA EVM Utils package now has some regression testing of the package, not of the Linux integrity subsystem yet, but I appreciate Vitaly's help in getting that there. It is yet to be upstreamed, but he posted that recently. And we have a couple of new LTP tests that were written by Peter. So, the next things that are gonna be worked on, which are being worked on, is we've tried multiple different ways of including Xaters and CPIO. And they didn't go too far because there's a couple of reasons for them not having been upstreamed. One is that every time that you try to extend CPIO, well, it's a standard and the standard is not being updated. It's a deprecated standard. And there needs to be a lot of work done to change different fields. So, the CPIO support is, we have a version of it that is only adding Xaters and not extending fixing other fields that need to be fixed like the timestamp and other things. And that is being done by Roberto and it just needs some people to review it. So, to review the code, to test it and to help us. I've reviewed it and tested it and it's on my queue to get it upstream, but I would appreciate any help that we can get in reviewing it. And the other major thing that I'm gonna speak about the rest of self-explanatory here is the updating of mutable file hashes. One of the problems that we have with mutable files is that if you pull the plug at any point before the file closes, if the file has changed, well, that file will not be in a good state and cannot be recovered. So, Yana is working on updating it and on updating it more frequently so that we can be able to reboot after a power loss or some other type of failure. I think the rest is pretty self-explanatory and thank you so much to everyone who's helped, who is helping and making the changes and we did release a new version of IMA EVM New Tills. The new, this is from, I'm not sure that this is readable, but this is the changelog of it was a major release because I hadn't released one in over a year, closer to a year and a half, but we now have support from Matthew for EVM signatures, other larger digests rather than just the Shaw one and we have support, Streebuck support, open SSL engine support and being able to read the PCRs, TPM two PCRs. And with that, any questions? On the new LSM security hook, security kernel load data, is there any LSM planning on implementing it or have they already implemented it for its use in the module? It's being used by IMA at the moment for preventing loading the K, loading kernel modules, the old CIS calls basically. So it is being used, it's just not being used by lockdown. Not yet, but some new LSMs may use it. Any other questions? Thanks, Amy. Thank you.