F20 System Wide Change: Enable kdump on secureboot machines
jreznik at redhat.com
Thu Jul 11 11:40:27 UTC 2013
= Proposed System Wide Change: Enable kdump on secureboot machines =
Change owner(s): Vivek Goyal <vgoyal at redhat.com>
Currently kexec/kdump is disabled on machines with secureboot enabled. This
feature aims to enable kexec/kdump on such machines.
== 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
* 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
== Scope ==
* 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
* 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.
* 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
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
devel-announce mailing list
devel-announce at lists.fedoraproject.org
More information about the devel