Allow kdump on secureboot machines
Summary
Currently kexec/kdump is disabled on machines with secureboot enabled. This feature aims to enable kexec/kdump on such machines.
Owner
- Name: Vivek Goyal
- Email: vgoyal@redhat.com
- Release notes owner:
Current status
Detailed Description
/sbin/kexec prepares a binary blob, called purgatory. This code runs at priviliged level between kernel transition. With secureboot enabled, no unsigned code should run at privilige level 0, hence kexec/kdump is currently disabled if secureboot is enabled.
One proposed way to solve the problem is that sign /sbin/kexec utility. And upon successful signature verification, allow it to load kernel, initramfs, and binary blob. /sbin/kexec will verify signatures of kernel being loaded before it asks running kernel to load it.
There are quite a few pieces to the puzzle. I am listing the some of the things which need to be done.
Build and ship ima-evm-utils package
- /sbin/kexec will be signed by evmctl. This utility will put an xattr security.ima on /sbin/kexec file and kernel will leverage IMA infrastructure in kernel to verify signature of /sbin/kexec upon execution.
- There is a bz open 807476 for inclusion of this package since long time. Not sure what it is stuck on though.
- There are some patches which are not upstream yet (like lock down executable in memory) which we need to carry in this patckage till patches get upstream.
Changes to kexec-tools
- Build /sbin/kexec statically. There is no infrastructure to sign and verify signature of shared libraries. Even if we can sign and verify shared libraries, currently kernel allows writing to shared libraries while these are mapped. So one can overwrite the library after signature verification. So build /sbin/kexec statically. kexec does not use nss related code, so there should not be any issues w.r.t glibc calling into other shared libraries.
- Generate detached /sbin/kexec signautre at build time and install these signature on target in seucurity.ima xattr when kexec-tools is installed.
- Modify kexec-tools so that it can call keyctl() and verify signature of a new kernel being loaded.
Kernel Changes
- Kernel needs to carry additional patches to do verify elf binary signature.
- There are patches to extend keyctl() so that user space can use it to verify signature of a user buffer (vmlinuz in this case).
- These patches are not upstream, so these need to be carried in fedora till patches get upstream.
- Kernel need to be signed using evmctl and detached signature need to be generated. These signatures need to be installed on vmlinuz upon kernel rpm installation in security.ima xattr.
Signing Key Management
Yet to be figured out. There are couple of ideas on table.
- Embed few keys in kernel and one of these keys will be used to sign /sbin/kexec. In case of a key is revoked, use a new key from set of embedded keys.
- Ship a PE/COFF wrapped key in kexec-tools package. This PE/COFF binary should be signed by appropriate authority so it can be loaded in system keyring.
Benefit to Fedora
Scope
- Proposal owners:
- Provide patches for kernel package.
- Provide patches for kexec-tools package.
- Provide patches for ima-evm-utils package.
- ima-evm-utils package will be new. It is not clear who will maintain that package.
- Other developers:
- Signing Process, Signing key management, Signing key loading on target after boot and Signature installation on target are unknown areas right now. It is not very clear how these things will be done. Once details have been figured out, it might require work from other developers. Not sure though at this point of time.
- Can't think any other major work required by other developers yet. We will have to figure out how signing will take place and how signatures will be installed on target system. And depending on how we do it, it might require some work from other developers. Like making use of rpm hooks to install signature etc. Given the fact that we are signing only one file /sbin/kexec, we might get away doing changes in kexec-tools spec file.
- Release engineering:
- We need to sort out how signing will take place. I will require release-engineering help on this.
- For issues related to key management I will need help of security/release engineering.
- Policies and guidelines:
- I think to begin with we might not have to update any packaging guidelines for this. Anything magic w.r.t signing can probably be limited to kexec-tools spec file.
Upgrade/compatibility impact
I think there should not be any impact on upgrade or compatibility. Old functionality should still be supported.
How To Test
- Get a system with secureboot facility and enable secureboot.
- Make sure kexec-tools package is installed.
- Do "service kdump restart". It should succeed otherwise test is a failure.
- Crash the machine using "echo c > /proc/sysrq-trigger" and it should successfully capture the dump.
User Experience
I think user should not see any impact of this change. Only thing they will notice that in F19 kdump was not working with secureboot and now it has started working.
Dependencies
- I don't think anything else depends on kexec-tools package
- ima-evm-utils package will be new in fedora so nothing depends on that either
- Upstream is not ready for the secureboot related changes yet. So we will have to carry all the package in various packages in fedora. So as such there is no upstream dependency.
- There is a dependency on build infrastructure and signing infrastructure so that we can figure out how /sbin/kexec signing will take place, how keys will be loaded etc.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?)
We can revert changes from kernel, kexec-tools and ima-evm-utils packages and rebuild these packages if we can't finish changes in time.
- Contingency deadline: Beta freeze
- Blocks release? No
Documentation
No documentation yet.