 Okay, so like everybody else, we have ten minutes for the integrity subsystem. So we're going to dive right in. So the Linux integrity subsystem has a number of pieces involved. And there's not really a lot of time to go through all the pieces. So we're going to stick with what's changed right now. And there was some major work done by Matthew Garrett on EVM. EVM protects the file metadata and IMA protects file data. So in order to protect file data, metadata, you need to include something. You have to bind the file data and the file metadata together. And originally, the way that we did this was we took something from the inode, the inode number, to protect, to be able to bind the two together. If you take something from the inode, that means that it's not going to be portable because it's different on every single system so that it's being installed on. So Matthew actually said, why can't we just use security.IMA as the identifier, the file hash as the identifier. And that's what he did. And so the new EVM portable signature allows it to be portable because it's included, but yet bind it to the file data. And it can only be used if there is a security.IMA on the file. By making it portable, it can now be used in package managers in any way else in order to carry it around. To, you know, to the file metadata can be included with the file data and is portable. Okay. And at the same time that he was working on this, he also, we now have a lot of signatures and he's not limited to just Shao Wan. So we now have support for larger EVM digest, just like we do for IMA and what else. And he'll be giving a talk explaining how to tie it at LSS Europe. In terms of the changes, the new features for IMA, we have, there were two ways of defining policies. One is the built-in policies that, the few built-in policies that can be used to bootstrap your system. And then you had the, and then they needed to be loaded at runtime to be, actually to be provided on the boot command line and they start from the very beginning. And then the idea was that we would transition into a custom policy and that you're starting from a fresh slate. Well, that's not how some of these, some of the things that distros want to be able to do. But I want to know that I can, that I'm verifying signature and that that signature is going to happen, that verification is going to happen even after a custom policy is installed. So we've now added support for a build-time policy that allows you to, that will allow the distros or anyone who's building their own kernel to say, I want to verify the Kexec, for example, the Kexec image and have that verified at runtime and no matter what other policy gets installed later, it will also verify, be included in that policy. The last thing that we've, which did not make it into 419 but is coming is the ability to differentiate based on the architecture what type of verification you want based on the runtime parameters, on the running system. For example, if you're in secure boot, then you might want to, you wouldn't want Kexec load to work, the CIS call, the Kexec CIS call to work. But if you're not in secure boot mode, you would. So the idea is based on the architecture what you want to do at runtime. So on x86, you have multiple methods of verifying the Kexec signature and so we're not limit, we're not saying that this has to happen all the time, but you get to decide what you want based on architecture. So IMA is being used and you've heard it mentioned a number of times today, but it's mostly being based on in closed environments, in embedded environments and to be able to move to a more generic kernel, we still need to close a number of gaps. So the biggest one was with iversion, not all file systems support iversion and we needed to be able to say, okay, what happens on those systems that don't support iversion? And what happens is that we can, we definitely know that if we can't detect when a file changes, then we know that we have to re-measure, re-appraise, re-do, we have to recalculate the hash. So that support is now in and then iversion becomes just a performance improvement. If you want the performance, then either use a different file system that supports iversion, add support for iversion for that file system and then the other example of not knowing where, when a file changes is the fuse file system. And so the question is, is the file, we can determine, we can't determine anything about the file. Even if we re-measure the file, there's no guarantee that the file that the fuse file system gave us is actually what's going to be presented later when we go to use it. So do we trust, and under what circumstances do we trust that the file, that the fuse file has changed or hasn't changed? So we now have unprivileged mounting of fuse file systems. And for those, we basically say we don't trust that the file system is going to give us anything the same a second time. In the case of privileged mounts, these are kind of inverted. The first one is saying we'll re-measure the file every time that it's used because we don't know, we can't detect when it has changed. And the other option, well, re-measure, re-appraise, do everything again. And the other option is to say, okay, we still don't know, even though it was mounted by root, we still don't know if the file has changed, and it could give us anything that we want. And these really should be inverted as to which is the default and which is optional. The problem is, is that if we do that, then we're breaking all of user space. So for now, if you don't trust fuse, then provide a policy that says fails safely on the boot command line. So there were a couple of problems that have been around. And the biggest one was that we reuse the IMUtex, the global IMUtex, and at the same time XFS also decided all of a sudden to drop their own local one and to use the kernel one. So we basically, there was a locking error. That has been, Dimitri Kazakin reintroduced our own IMUtex, our own locking. And so that problem is now resolved. The TPM performance has improved tremendously. The first thing that we did a couple of years ago now is that we went from M-sleep to the HR timer, and then improved the TPM performance. But this year, further work has been done by Naina, and she's getting about a 83% performance improvement. And my colleague, Stefan, has with the audit people here, with Paul's help and others' help, has disambiguated some of the audit records. And so now, as soon as the auditing IDs are up there, we'll start to be able to do the namespacing. And the first, the IMA namespacing, and the first one will be based on audit. So there's IMA audit, and that will be probably the first namespace, IMA namespacing. So thank you, Peter. I think that's how you pronounce his name. He did a lot of work on the IMA measurement testing tool, test that's in LTP, and it's now, it hasn't, hadn't been refreshed in quite a while. And so that work has been upstreamed. David Jacobson worked with our team in writing, starting to write a regression testing framework for IMA, like EVM, it's in the IMA, it will be in the IMA EVM utils. It needs some review, but that is going, that's going to happen. And the purpose of it is so that we can have a standalone test suite, just like Casey was saying, having test suites and regression testing. And this is really important, so that other parts of the kernel aren't breaking it, and everybody can do their own regression testing. And it's meant to be used directly on the running kernel. And patch is once it is upstreamed, it will be included in IMA EVM utils, and then the exifest introduction and usage of that will be upstreamed as well. And I assume that an equivalent one for LTP will be upstreamed. These are all the things that are in progress, that are being, that were mentioned today. Some of them, some of the talks will be given at LSS Europe, that were, that are not being given here. The one that will be at, that's being given at LSS Europe is about the measurement list and how to protect the measurement list that addresses the IMA measurement list. But, and lastly, how to help. We need more people to be reviewing patches. We have people that are, are posting patches, that don't review other people's patches. And we could definitely use some help with getting some more reviews. And those that are posting patches should be reviewing patches too, to help the community. The other aspect of this is that we need more people to be saying, what is appropriate for IMA? IMA is being taken in multiple different directions. Everybody wants to do something with it. And the question is, is this appropriate? And there needs to be more of a discussion rather than just me saying, answering that question. And yeah, for those that want to help with policies, we're looking for sample policies that can be used and to include them. And lastly, new functions, new features are being upstreamed. And please think about signature that everything that gets upstreamed should require, there should be ways of not breaking IMA. And don't introduce new measurement, new measurement appraisal, other types of gaps. Thank you. There's been a lot of, for the work, the automated testing work. For the minor bug fixes, they're not minor, but not included in the whole list of what was upstreamed. And the help for the SSL help and other packaging issues that we had with IMA EVM utils. I just had one comment. I was thinking if you're looking for input on where to take the integrity subsystem apart, as well as here maybe submit a proposal for a microconf to the plumbers. Plumbers conference might be, Linux plumbers might be useful to get people, because we've had successful things with TPM in the past. Right. They're getting user land and to scroll for involved. Any questions? Thanks. Thank you.