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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
