 Good morning for those attending in person. Good afternoon, and good evening as maintainer of integrity system. I normally describe other people's work this year and instead of my describing their work. I've invited Lakshmi and to share to join me in describing their work in defining new I'm a buffer and critical data measurements. This work is really important and will be used in a lot of different places. Let's try. Thank you, Mimi. Hi, my name is Lakshmi. I'm a software design engineer in Microsoft. I've been working in the integrity subsystem in the next kernel for the past two years. Thank you, Mimi. Thank you, Lakshmi. My name is Tushar Sugandhi. I'm also a software developer at Microsoft and for past two years I've been working with Mimi and other Linux kernel maintainers on various subsystems like IMA and device mapper and all. Thank you. Afterwards, after to try and much we do their section, I'll continue as per usual by describing other people's changes already upstream and some really close to being upstream. As you're aware, IMA has dependencies on the TPM key, key rings, asymmetric key. EVM is dependent on the trust key type, which was upstream to support the EVM HMAC key. So though they aren't part of the integrity subsystem, the integrity subsystem is dependent on them. And for that reason, I'm including them in this presentation. Two themes this year, as you'll see, are generic and generalizing codes that we'll be discussing. Lakshmi. Thank you, Mimi. We have streamed two buffer measurement features in IMA. The first one measures the command line argument passed to the new kernel in the kexec system call. This is enabled to this custom policy. An example is given here named the kexec underscore cmd line. The second measurement is measuring X519 certificates when the key is imported to a key ring. This is enabled through this custom policy rule named the key underscore check. So in the first example, it enables measuring keys imported to any key ring. But if you want to limit measuring only particular key rings, then we can specify the key ring names in the policy. So in this example, the measurement is limited to keys that are imported to the dot IMA key ring or the dot EVM key ring. These measurements are really critical. It enables a remote attestation service, for example, to verify that the system, when a new kernel is loaded onto the system to the kexec system call, the only known valid command line arguments are passed to the kernel. And with respect to the certificates, it enables the remote attestation service to verify if known trusted keys are imported to the key ring. And when X519 certificates measurement becomes all the more important when the feature for a new root of trust for safely loading keys from, for example, mockdb is upstreamed. And we also upstreamed tests for these features in LTP. Tushar. Thank you, Lakshmi. So we also, along with the buffer data measurement, we also worked on supporting critical kernel data measurement. So what is the critical kernel data measurement? IMA measures files and buffer data such as keys or command line arguments passed to the kernel on kexec system call, as Lakshmi was mentioning. While these measurements are necessary for monitoring and validating the integrity of the system, they're not sufficient. Various data structures, policies and states stored in the kernel memory also impact the integrity of the system. These structures are data sources can be called as kernel integrity critical data. Some of these structures cannot be defined as read only after in it because they are initialized later and they're not expected to change frequently during runtime. Several kernel subsystems such as contain such integrity critical data. For example, LSMs like SELinux or AppArmor are various attributes of device mapper modules like DMCrypt, DMVarity that we described in yesterday's talk on device mapper and IMA measurements. These are the examples of integrity critical data. We have upstreamed some of the critical measurements already. For instance, SELinux and device mapper critical data. The SELinux critical data measures the hash of the SELinux policy. The SELinux operating mode, the operating mode can be either enforcing or permissive. We also measure several other SELinux policy capabilities as described in this example. For example, enabling extended socket class capability enables the support for all the known network socket address families. And we measure if that capability is enabled or not. On the device mapper front, we measure the critical data from various device modules like DMCrypt, DM Integrity, DMVarity, etc. For example, in case of DMCrypt, we try to measure what is the encryption algorithm and key strength used for disk that are being encrypted using DMCrypt. In case of variety, what is the root hash of the read only disks like OS boot volumes that are configured with DMVarity for secure boot. So we measure all these attributes for various device mapper modules. And lastly, we also added the support for allowing the duplicate measurement records in order to detect critical data or file change reversion. This change ensures that the up-to-date measurements are provided by the system to the remote attestation services. Thank you. Thank you. The security IMA X adders contain either file hashes or signatures. Anyone with real root privileges may write security.IMA X adders. Up to now, file signatures can be based on any hash algorithm. One reason for this patch set is to prevent writing unsupported hash algorithms. And the other reason is to prevent inadvertent downgrading of file signatures. For example, files signatures may already exist on the file system. Migrating from an existing hash algorithm to another requires allowing the existing file signatures to continue to be verified. But at the same time, preventing downgrading the new file signatures. As seen in the example, policy rules, the praise algorithms differ. On a soft reboot, the TPM PCRs are not reset. As a result, carrying the IMA measurements list was originally added for open power. This work was done by Tiago Bowerman. To Char and Lakshmi, the Tiagos and Rob Herring's help generalize the support for device trade. Another example of generalizing support is the architecture policy support. The existing IMA architecture policy for X86 was generalized for EFI by Chester Lynn with Ard's help. It measures both the Kexec kernel image and kernel modules. It also requires them to be signed. There are different ways that they can be signed. It requires a single method. Revitasso vastly improved the existing portable and immutable EVM signature support. The list here includes a lot of the changes that were made. As much as possible, IMA and EVM are two separate subsystems and shouldn't be mixed. The one exception is including EVM signatures in the IMA measurement list when an IMA signature does not exist. As previously mentioned, the trusted type keys was upstream to support EVM HMAC. Even prior to extending trusted keys to other hardware, the guarantees differed for hardware versus software TPMs. The extending trusted keys to support other hardware highlighted the need to document that not all trusted type keys are equivalent. The trust source section of the trusted encrypted key document is an attempt at documenting that. Currently, the only way of verifying new routes of trust is by building your own kernel and embedding a local CA key in the kernel image, which would be loaded onto the built-in key ring on boot or post-build by embedding the key into the kernel image and resigning the kernel. Most users aren't interested in building their own kernel or even just embedding a key post-build and resigning it. Being able to load a local CA key from a trusted source is really needed, but what makes it safe? Eric Snowberg has posted a pass set a number of times, which is really close to being upstream. His version, the trusted source, is the MACDB, but it's clear that other sources, trust sources, will be defined in the future. Thank you everyone who has contributed, especially Peter Voral and Vitaly, for the contributions to IMA EVMU tools and the IMA LTP test. A lot of work has gone into both of them. I'm hoping to release a new version of IMA EVMU tools in minutes. We mentioned two themes, generic and generalizing code at the beginning. Initially, people think about their specific problem without looking at the bigger picture. Please remember to look at the bigger picture and see if it is something that should be generic. As we've seen with both the buffer and critical data measurement, the code being streamed is a lot simpler and cleaner. Questions?