On Thu, May 28, 2015 at 11:26 AM, David Sommerseth <davids(a)redhat.com> wrote:
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
Where can I read more information on this project, and why that might be?
It is worth noting that Fedora does not allow packages other than the
kernel to ship kernel modules.
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 . 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.
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!
You are correct here.
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
* 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?
The above approach seems mostly sane. It does seem like a lot of
hassle, but it's what is required if you want to leave SB validation
enabled. Otherwise, you could have your preparation script disable
mokutil validation at the risk of no longer leveraging the SB
protections for grub, the kernel, or the kernel modules. Shim is
still validated by UEFI itself as SB is still enabled in the firmware.
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"
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!
I'm not aware of any. The one place that might be worth looking is
rpmfusion, as I would expect they need to do something similar for the
kernel module packages they build if they care about running with SB