 Okay. Hi everyone. Good morning. So, as Eleanor said, Tiago and I are presenting on using Linux as a secure boot loader for open pass servers. So, we both are from IBM. We work for Linux Technology Central in IBM and both of our contributing to the kernel. This is a disclaimer to start with. This work represents a view of the author that is both of us and does not necessarily represent the view of IBM. All design points disclosure in a subject to finalization and acceptance and they may or may not be the part of the final product. Less of the things as there. Okay. Here is the agenda. We will start with the secure boot goals and requirements as per open pass. And to satisfy those requirements, we are trying to see what the existing mechanisms in the kernel which we can reuse. There are some gaps in that and we will talk about them and we will also talk about our proposed solution. Then finally the patch status and the summary. Okay. To get started. So, secure boot goals and requirements. I assume here everybody would be knowing about secure boot and we have heard about it either in other slides or in the previous LSS. So, it's still just to give a brief overview. It is a protection against boot kits and the root kits. And it is basically to make sure that any firmware or any operating system you load on the server is basically verified, genuine, and from the owner as you expected. So, this is the same what we are targeting. It's for the open pass secure boot solution. The second thing is it's also a requirement for the standards complaints and two of them as I listed. This SP 8147B and common criteria OSPP 4.1. Okay. I'll first start with the open pass secure boot high level overview. And then we will see what problem actually we are focusing into the whole solution. So, here is the firmware secure boot and OS secure boot as you see. Okay. The open power, the root of this, it starts with the SB, which is basically a sign of tested code embedded into the hardware. And, okay, sorry. I think my hands. Yeah, embedded into the hardware and from where the chain of trust actually starts. As I told, every in secure boot, every image before loading the next image is supposed to verify it. And that is what is done. The SB verifies the host boot. Host boot verifies ski boot, which is also called as OPAL, and ski boot verifies the boot gunner. These are the part of the firmware and they are stored in the process of flash as a signed firmware containers. These signed firmware containers are actually the headers which are prefixed before the images and they have a defined format. It's that the overall secure boot perspectives are being discussed in other addresses and we are not going into details of that. This process of flash is not locked, so we protect the signed firmware containers via TPM. Now the next point comes is the OS secure boot. So once the boot loader is there, boot kernel is there, it needs to load the host operating system. The open power boot loader is actually a kernel based loader, which is a petite boot. It's a user-specific application running on the kernel, which loads the kernel images from differences options and then Kexecute as a host source. Today's discussion is actually about making sure this part from the boot kernel to the host source verifying the kernel images, which is the requirement for as part of end-to-end secure boot solution. So getting into the boot loader details. So as I said, it's a Linux kernel based boot loader and petite boot is the application which does the Kexecute. It can load the images from different mechanisms, either as a network from local days, Clemson, etc. And then the host source can continue the chain of Kexecute, which is common for any other Linux possibilities. So requirements. Okay, we need a verified kernel that is a requirement, core basic requirement for the secure boot. This kernel can be fetched from any multiple ways and we have to make sure that whichever way we get the kernel, it should be verified before loading. The second thing is that the secure boot solution, basically a system can be in a different mode as part of the secure boot also. It might be in a setup mode, which may not require you to do the verification. It might be in the audit or user mode. The user mode enforces that you verify everything. And the audit mode tells you to do the verify. But even if the verification fails, it allows you to boot. It just logs that the verification has failed for later analysis. So these different states of the secure boot needs to be honored. The policies as per them has to be honored. Then you need the firmware key support. It is possible that your firmware is signed with a set of firmware keys and your kernel image is also signed with the same firmware keys. For example, DB, KEK keys. So it is required that the kernel can verify the boot loader, can verify the kernel using these firmware keys. Maintain the secure boot policies across the Kexecute. When the kernel does the Kexecute, it can change the boot parameters option. So it is possible that people can try to do overriding. So what is required is that based on the secure boot state of the system, these policies should be maintained across any set of Kexec chains. And we need that the Kexec load is disabled because Kexec load allows unsigned kernel images to be loaded. And the last thing, as I said, as shown in my first diagram, we actually divided it into two domains. Firmware and the operating system secure boot. Because the OS secure boot kernel images can come from various options, but firmware is from the platform owner. So it is possible that sometimes you distrust, might want to load unsigned kernels for backward compatibility, but then you don't want to disable the whole secure boot solution. So your firmware secure boot is still enabled, but it allows unsigned kernels to be loaded. So that is the last point. So the thing is, we need this for our last stage of loading the hostOS. And we have a kernel-based bootloader. So the point is, can we use something which already exists in the kernel? And from yesterday, today, and all of earlier discussions, people know about integrity measurement architecture somewhere. So we consider this as a possible solution. Tiago will discuss about that. Okay, hello. So AIMA, as we have seen here today and in other presentations and conferences, AIMA is a major subsystem in the kernel being used in production. So we turned to it to implement secure boot. It can be used to enforce the secure boot rules that we want. So how does it work to have a secure boot implemented using AIMA? When the bootloader starts, it has to check the secure boot state, which can be audited, our setup, our user mode. And depending on that, it will load the firmware keys to the kernel key ring. And we'll load the policy that will enforce the secure boot settings of the firmware. And finally, it will be ready to verify the kernel before allowing it to be loaded and booted. So, well, I will not spend a lot of time with AIMA basics. We had talks here about that already. Basically, we have three operations in AIMA, measure, appraise and audit. When you measure, you can also start the measurement in the measurement list, as was said before. And at the top here, we have an example with AIMA policy with three rules. The rule in the middle here is the one we are most interested in for secure boot. It appraises the kernel that is loaded via a KSEC file load. And the argument here appraised type equals AIMA sig is telling AIMA to verify a signature stored in the file. So, how do you do that? You have to use the AVM CTL command, which will add the security dot AIMA extended attribute that extended attribute contains a signature in a very simple format as can be seen here. And with that, AIMA is able to retrieve that signature and verify if the kernel is correctly signed. So, if this works and it does, then what's the problem? We found three issues that we solved and we are going to expand on them during this talk. I will explain the first one and Nina will go into more details on the next two. So, the first one is related to the use of extended attributes. It's a very common method when you boot your computer that you fetch your kernel from the network. And some methods of booting via the network, they will not allow extended attributes to be fetched. For instance, HTTP or TFTP or even local file system, some file systems used for USB keys. For example, they don't support extended attributes. So, we need to support secure boot even in those scenarios. So, this is a problem we have found. So, well, just to reinforce, these are examples of boot methods that Peteyboot allows. They're fairly standard in bootloaders. Some of them allow extended attributes, some don't. So, our solution involves embedding the signature in the file. The kernel has a method for that already for module signatures. There's a kernel feature where you can require that modules are signed and only sign-in modules can be loaded. And the format of the signature is very simple. You just append at the end of the file this structure which contains a pkcs7 message with a signature. This suits us because the PowerPC kernel is an elf image as well. You can append contents to it and it will still be usable. That's what we decided to use. There's a tool already in the kernel script slash sign file that performs this step. So, that's what we use. When we added appended signature support to AIMA, we wanted to do it in a way that's backwards compatible in the sense that if you already have a file that has an extended attribute signature, nothing will change if that file has an appended signature as well. So, what happens is that if there's no... Well, the first step is there's a new argument you can pass to the appraise rule which says to AIMA that it can expect a modcig. We allow it to use a modcig to verify the signature. And if you have that and there's no extended attribute signature in the file then, of course, AIMA will look for an appended signature and try to use it. And the other case is if there is an extended attribute signature, but the signature is signed with a key that the kernel doesn't know about. It's not present in the kernel key ring. So, in that case, it will ignore the extended attribute signature and also look for an appended signature in the file and try to use it to verify it. So, even though secure boot is not about measurements, there is an interaction with measurements that we found that we had to address. So, I'm coming back to this measure step and storing it in the measurement list. Just an aside, the rule in the middle has the setting that I mentioned that you can add. In the appraise rule, you can say appraise type equals AIMAcig or modcig. Then you are telling AIMA that it can use a modcig if there is one. So, before I talk about our issue, how does AIMA know what to put in the measurement list? It has a concept of an AIMA template. The AIMA template tells it which information should be added to an entry in the measurement list. You can use template fields for saying that you want to store the digest, the name of the file, and if there is a signature, a signature as well. So, there are some predefined AIMA templates, for instance, the AIMA-cig here, which includes the signature. In that case, you have a measurement entry like this one. Just to explain a little bit, the first number here in yellow is the PCR. The TPM PCR that is extended with this measurement then follows the contents of the PCR at the time of this measurement. And then you have the template that AIMA is configured to use. In this case, AIMA-cig, which as shown on this slide, tells that AIMA should store the digest, the name, and the signature of the file. So, that's what follows here in blue. This is the SHA-256 digest of the entire contents of the file that was appraised, the path of the file, and then at the end, the contents of the security.IMA extended attribute containing the digital signature. So, one property of these that is very useful is you can, just with this entry, during audit, for instance, know whether the signature is valid or not for this file. The digest of the file is the digest that is used in the signature to validate the contents. So, with this digest and this signature, you can say whether the signature was valid or not when the file was appraised. The problem we found is that when you append the signature at the end of the file, you modify the file contents, obviously, and with that, the digest of the file as measured by AIMA is not the same one that was used to sign the file anymore, and you can't, at a later point, verify whether the signature was valid or not. So, we solved this by introducing a new template field called d-sig, which tells AIMA to store not only the, sorry, it tells AIMA to store the contents, the hash of the contents of the file, but ignoring the appended signature at the end. This field, this hash then is the one that is expected to match the one in the signature, and here in this example, we see at the end of the file the contents of the appended signature as well in the entry, and with that information, we can once again verify that the signature is valid or not when the file was appraised. One last point that's also not directly related to secure boot, but important in our use case, every boot is a KSAC in open power, so if you want to verify the contents of the PCR registers in the TPM, you need the history of measurements that were made because when you KSAC and you kernel, the TPM is not reset, so the PCR contents are not reset either. You need the history of the measurements in the new kernel to know whether the PCR values are the ones you expect or not. Also, you need to know at which boot, which kernel each measurement corresponds, so you have a measurement you want to know if it was before a given KSAC or after a given KSAC, so you need a marker for the KSAC event, and IMA has the boot aggregate that serves that function. You have one boot aggregate per KSAC that you perform, and lastly, you also need the measurement list passed to the new kernel because the act of performing a KSAC file load itself generates new measurements and you want them passed on so that you can verify the TPM PCR values. So we have a feature already upstream since kernel 4.tem on PowerPC where when you perform a KSAC file load, the kernel will serialize the IMA measurement list into an IMA KSAC buffer and pass it on to the next kernel. Then the new kernel will detect that this buffer is there and will load the measurements into its own measurements. Sorry. No problem. Sorry, I think I'm talking too much. But I'm at the end. So these summarizes how we solved the first issue that I mentioned before in the earlier slide. It solves our problem with extended attribute signatures by using the module signatures. So now, Naina will talk about the other points. Yes. So if you remember from the Mimi's slides, there are three things required for the IMA present. First is signature, then the keys and the policies. Now, we have the kernel with the signature, but we need the keys to verify those signatures. And as I mentioned that one of the requirement is that it is possible that you get the firmware keys to be loaded. The kernel images might be signed with the firmware keys and we need to load these firmware keys in the kernel for verifying. So what's the problem? There exist key rings. Yeah, from David Hall's presentation, people might have an idea about key rings. So there exist key rings and dot IMA and underscore IMA. Like it is used by the IMA for appraisal. So store these keys into the, store the firmware keys into these key rings. But what is the problem? Let's see. Dot IMA actually accepts only the signed keys. And these signed keys are watched by the keys which are present in the dot secondary and the dot built-in trusted keys. And the point is that we want to emphasize is that the dot built-in and dot secondary should have only, are actually accepting only signed keys. That is because since they are watching the keys, if they are unsigned and if somebody puts an unsigned malicious key, they might end up watching most of the other malicious keys which are there in, which may be loaded into the dot IMA and can be used for the IMA appraisal. So this is the like dot secondary and dot built-in that's to expect only the signed keys. And the same that the dot IMA then needs the keys which are signed and watched by these two. Underscore IMA is the one which is the user's defined key ring. And it can accept the keys which are unsigned and generally loaded, typically loaded in the MFS before the system privates root. The second key property is the modifiability. The built-in trusted keys are actually compiled in time you define, you add the certificate. But the other keys can be modified via the user space. And the scope, the limited and broad. So the, as I said, the built-in and secondary keyings are used for verifying other keys or for the model signatures. That's the only purpose for them. So that's why we say scope is limited. But for the dot IMA and underscore IMA, keys are used for multiple purposes. So now if we see and if we need a firmware keys to be loaded, what is the requirement? Keys come from the firmware. The first question is, does the kernel trust the keys which are coming from the firmware? So you can also see in another way pre-boot keys or the post-boot keys. That is one thing. Second thing, since the keys are provided by the firmware, we would not want any user to be able to modify them. And if we try to match, none of these actually are satisfying this. So I need a compile link here loaded from firmware. But the kernel may not trust them. And also, the firmware keys may not always be signed. So I may not be able to verify their signature chain of trust. Secondly, these are used for, the scope is only to use them for the kernel image verification. And they should not be user-modifiable. Now, if we, so that's where to satisfy these three requirements. We propose a new key ring, which is called the platform keys. And the purpose of this is that you load the firmware keys. Basically, you need to provide an isolation. The kernel has to isolate the keys provided by firmware, which may be unsigned, and the keys which its own provides from the kernel itself and which it trusts. So this platform key ring, the purpose of this is to provide that isolation between the untrusted firmware keys and the trusted keys. It can be loaded either the compiled in time as a single certificate or loaded from the boot time. These accepts unsigned keys. They need not be satisfied any chain of trust. And then the node-modifiable, they should not be overridden by user-respect. So basically, these keys, once loaded at the boot time, nobody can change them. We can enable this by a config option, config platform key ring, and config platform trusted keys. So here is how it looks like. Dot platform keys, it has the same permission as the dot built-in because it doesn't, it need not be modifiable by user. And yes, that's what they think. So this actually provides a, it allows us to use the firmware keys, which comes from the pre-boot time, may or may not be signed to be used by the bootloader for the kernel image verification and only for the limited purpose of the kernel image and are not modifiable by user. And that's how we solve this problem. The second thing, so again, the third thing which is required for the appraisal is the policy. AIMA will do the appraisal only if there is a policy defined for it. And we need KXK kernel, check is the existing policy rule which can be used for the kernel image verification. But what's the problem that's discussed there? These are the default policies. These are the existing policies available now. The upper two are more of default policies for different purposes. Our focus is more on the secure boot and the secure boot specific policies which has a KXK kernel check. So the last two does that. The secure boot policy is defined as a boot parameter and it can be overwritten by the user space by writing it to the syskernel security AIMA policy file. This is not preserved across KXK because I might have loaded my host source with the boot parameter secure boot, but I can do another KXK without this parameter and there are no secure boot policies anymore. The second option to fix this, the next option that comes is the build time policy so that it cannot be modified by the user. And so here, these are defined at the compile time. This has come recently, so these are defined at the compile time. We have to choose them as a config option. And they are same policies defined with the KXK kernel check as secure boot. They are not custom-modifiable, but the problem is these are hard-coded. Once it's built, it's returned, it's built into the kernel, it's built. Those won't handle the secure boot state of the system because that is what we need. We need something with this runtime which at the boot time understands the state, secure boot state of the system, whether it is an audit mode or a user mode or a setup mode because the setup mode may not need any verification, but the user mode needs verification so it can define the policy, it can check the policy accordingly. It should not be custom-modifiable, nobody should be able to override it and it should be preserved across KXK. Since every KXK will actually should be checking the secure boot state and accordingly defining the policies, and the state of the system will not be changing, so that way it can be preserved. So to handle this, we propose another policy called architecture-specific policies which can be defined specific to each architecture based on their requirements and these are loaded at the boot time. These are based on the secure boot state. They are of the highest priority. If these are defined, no other policy will be overtaking them. These are the ones which are given the priority. They cannot be overdone by boot parameter because these are specified at the runtime. No boot parameter is required to define them. One more thing is there is an IMA press-type flag. You can make it... the IMA press-type can be used as a log and force or fix. So I might have defined the policies, but if I make the IMA press equals to fix or log, I can still boot an unsigned tunnel. So this flag has to be very carefully used along with the policies. So when the architecture policies are enabled, the IMA press-type option, boot parameter option is disabled so that it can be configured again at the runtime. This option can be enabled by IMA ARC policy. Here I'm showing an example of the policies as we are considering for the open-power solution. For the setup mode, we do want to do measurement, but we don't want to do the appraisal, and this is where it's the... don't appraise, but for the audit and user mode, we want to do both measure and appraise. So based on the secure boot state, the runtime, the code will actually load one of these. So we started saying that IMA can be used for this in a generic way, but we found some problems. We just talked about the solutions for those problems, and if we combine them all together, here is how you see the solution of it as a complete work. The boot kernel is loaded. It checks the secure boot mode of the system. If it is in the setup mode, we don't need any kernel verification. So no keys are loaded onto the platform key ring. No policies are set, but if we get into the audit or user mode, we need the keys, so we load them. We need the keys from the platform, so we load them to the platform key ring, and now these keys are locked. Nobody can modify them later, and these are isolated from other keys of which the kernel uses. These are specifically available only in the platform key. If it is in the audit mode, the policies for audit and the user mode are the same. The only difference is the IMA press flag is logged for the audit mode, but in case of the user mode, IMA press flag is enforced, because here we want to make sure that if it fails to verify the kernel, it just doesn't boot. Then we have the keys, we have the certificates, we have the policy, and the petite boot fetches the kernel image. It verifies the appended signature. We have the appended signature on it, so it verifies the appended signature, and if it is verified, then host service is loaded. This is how all three solutions for those developments combined together gives us a complete solution. Here is the patch set status. We talked about three features, appended signatures, platform key ring, and architect specific IMA policies. The two patch sets IMA support for appended signatures and the platform key ring are awaiting the acceptance. They are posted and are available on these reference links. For the IMA support for architecture-specific policies, we are soliciting acts and reviews for the ecetistic-specific patches, which we have in that. Then the carry IMA measurements file across Kexec is already up to stream, as Tiago mentioned. Then the loading keys into the platform key ring, these are based on David Hovel's patches, his patch set keys, blacklisting and UEFI database load. We have used two patches in that, like add EFI signature data types and add an EFI signature block parser because OpenFAR also uses the ESL format for the keys. This is a work in progress, and the power-specific art policies is the work in progress. In summary, IMA provides the kernel-based solution for verifying the hostOS to give us a secure boot solution, I mean as part of our end-to-end solution. We had three problems out of it for the key ring, for the signature, and for the policy, we fixed them by introducing platform key ring, icon-specific policies and appended signatures. We have the patch sets either in the state of up-streaming, awaiting acceptance, or awaiting reviews or work in progress. We welcome the community to test them, give their reviews back, give your inputs and feedbacks, whatever you think about those. And this is where I have the demo for these patches. If anybody is interested, I can show that later afterwards. These are the references, and this is acknowledgments for our team who had worked, the IBM LTC security team who is working, and we work in collaboration with the security research group, and the IBM Power Security and the Power Formula team. Yes. Questions? Could you give us some more details about key exacting crash kernel and signing its user space? So, what details do you need? Actually, key exact is very often used to launch a crash kernel, which is able to export the memory of your crashed kernel and use PROC VM core to dump its memory. Is it somehow affected? And there are two, in this, so basically the key exact file load is doing the signature verification, and then in order to, and there are two patches in this patch set which disable key exact load as well. If you have the IMA policy, then, and you're using the, and you're using the IMA signature verification, then it will prevent the key exact load. But if you're using the regular signature verification, kernel, the architecture specific one, then if you're not in secure boot mode, it won't disable the key exact load. So, it depends if you're in secure boot mode or you're not in secure boot mode. Right, that was the compromise. No questions? If not, let's thank speakers.