Secure boot and packaging third-party kernel modules

David Sommerseth davids at redhat.com
Thu May 28 15:26:51 UTC 2015


Hi,

I've started poking into packaging the mhvtl project for Fedora and
EPEL.  This package also contains a kernel module, which normally works
fine - until you hit Secure Boot.

So I was wondering how to handle this the best way.  AFAIK, there are
currently no plans to get the mhvtl.ko kernel module into the upstream
kernel.

Some packages (VirtualBox, IIRC) can compile the kernel module
on-the-fly if it is missing during boot.  That's an easy thing to
implement.  But for secure boot, things gets complicated as the kernel
module needs to be signed.

I've played with mokutil and the sign-file script which is in
kernel-devel, based on this article [1].  This all works fine.  I could
easily install my own key, compile the mhvtl.ko module and sign it.  And
then it was possible to load the module.

[1]
<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html>

It's also important to remember that kernels do get updated.  So when a
new kernel is installed, it is (to my knowledge) required to recompile
the module.  If I'm mistaken, please educate me!


My current idea to solve this is to:

* Have a "preparation" script which the admin is required to run
  on a new system.  This scripts generates the needed key material and
  runs mokutil which installs the key.  It will then provide enough
  information so that the admin can reboot the system and get the MOK
  key installed.

* Have a unit file which runs a ExecStartPre= script.  This script
  will check if the key material exists.  If it does, it will check
  if the mhvtl.ko module for the currently running kernel exists.
  If the module is missing, it will compile it, sign it and load it.
  Failures along the way will cause the unit file to fail all together.
  When the ExecStartPre= script has completed successfully, it will
  start the needed processes it normally would do.


Any thoughts or comments to this approach?  Anyone got a better idea?


Yes, I do know it is not good to have the keying material for the
signing too easily available.  So I'm also keen to hear ideas how to
protect the key better.  With that said, I'm planning on only providing
access to the key file to the root user only.  And I'll look into if I
can restrict the accesss even further with some SELinux rules (so only
the ExecStartPre= script can access it together with the "preparation"
script.

Another thought ... Are there other packages who could benefit of such a
solution if it was made more generic?  I'm willing to investigate into
this too, if there are more users out there ... Or if someone has
already done that - no need to reinvent the wheel!


--
kind regards,

David Sommerseth


More information about the devel mailing list