Re: Secure boot and packaging third-party kernel modules
On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Sex, 2015-05-29 at 08:54 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. This is a good subject for RPMFusion and all his kmods ... , but I really don't have time to think about it . In Ask we got examples of kmods signed for VirtualBox under Sercure Boot : https://ask.fedoraproject.org/en/question/68285/best-way-to-install-virtualbox/?answer=68413#post-id-68413 https://ask.fedoraproject.org/en/question/34470/virtual-box-on-fedora-19-fails-to-start-a-vm/?answer=59222#post-id-59222 Seems possible ship kernel modules on the fly since fedora package kernel also does it (it seems), I read that somewhere. Best regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 28/05/15 23:03, David Smith wrote: On 05/28/2015 10:26 AM, David Sommerseth wrote: ... stuff deleted ... Any thoughts or comments to this approach? Anyone got a better idea? Your process looks reasonable. Thanks! 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. Systemtap has a similar problem. By definition, we compile kernel modules and still need to work on a secure boot system. To solve it, we automated the process you outlined above and added it to our existing compile server functionality. On a client machine you ask for a systemtap script to run, and behind the scenes the script gets shipped off to a compile server that has a matching kernel devel environment and matching MOKs. The signed module gets shipped back to the client system and run. The advantage we have here is that if you have lots of client systems, none of them have the private MOK key installed on them - only the server has the private key(s). We only pass around public key fingerprints. Right, that sounds like a good approach when you have a compile server. For the mhvtl project, having a compile server isn't really the right solution. 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! Systemtap's solution is probably pretty specific to ourselves, but the general idea (and perhaps some code) could certainly be borrowed. Cool! Thanks for the pointer! I'll have a look at systemtap. But really the best solution here is to get the mhvtl kernel module upstream. Agreed, but I'm not sure how keen upstream kernel developers are to carry a driver for virtual tape devices. I've asked mhvtl upstream if that has been considered, but currently I'm not convinced that will happen any time soon. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Fri, May 29, 2015 at 9:19 AM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 08:54 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. This is a good subject for RPMFusion and all his kmods ... , but I really don't have time to think about it . In Ask we got examples of kmods signed for VirtualBox under Sercure Boot : https://ask.fedoraproject.org/en/question/68285/best-way-to-install-virtualbox/?answer=68413#post-id-68413 https://ask.fedoraproject.org/en/question/34470/virtual-box-on-fedora-19-fails-to-start-a-vm/?answer=59222#post-id-59222 Seems possible ship kernel modules on the fly since fedora package kernel also does it (it seems), I read that somewhere. Er... no we don't. The kernel package provides all it's modules already built. It doesn't build any on the fly after it is installed. I'm not sure where you read that. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? [...snip...] 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? 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. I generally prefer the most strict approaches, I don't want users to feel that a package I introduce may lower the overall security in any way - unless that is the only working alternative. I do see it doesn't makes it easy to implement, but that's how it is. 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! 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 enabled. Thanks! -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 29/05/15 14:54, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. I have asked the mhvtl developer about this, still awaiting an answer. I would generally prefer seeing it upstream kernel, but until then I'd like to have a solution in place as well. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. Fair enough! -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Fri, May 29, 2015 at 5:57 PM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 09:28 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 9:19 AM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 08:54 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. This is a good subject for RPMFusion and all his kmods ... , but I really don't have time to think about it . In Ask we got examples of kmods signed for VirtualBox under Sercure Boot : https://ask.fedoraproject.org/en/question/68285/best-way-to-install-virtualbox/?answer=68413#post-id-68413 https://ask.fedoraproject.org/en/question/34470/virtual-box-on-fedora-19-fails-to-start-a-vm/?answer=59222#post-id-59222 Seems possible ship kernel modules on the fly since fedora package kernel also does it (it seems), I read that somewhere. Er... no we don't. The kernel package provides all it's modules already built. It doesn't build any on the fly after it is installed. I'm not sure where you read that. Sorry, I meant, the kernel package sign on the fly (the kernel modules) ? No it doesn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Friday 29 May 2015 15:24:24 David Sommerseth wrote: On 28/05/15 23:03, David Smith wrote: snip But really the best solution here is to get the mhvtl kernel module upstream. Agreed, but I'm not sure how keen upstream kernel developers are to carry a driver for virtual tape devices. I've asked mhvtl upstream if that has been considered, but currently I'm not convinced that will happen any time soon. As a different route, if upstream are still active, have they considered using LIO's TCMU interface[1]? Combine this with tcm_loop to provide local access to the LIO SCSI targets, and it looks to provide the same featureset as mhvtl's kernel module, using existing kernel infrastructure. Note that I've not dived in deep enough to confirm that LIO is a competent solution here, but it looks like it provides the features mhvtl needs. [1] https://www.kernel.org/doc/Documentation/target/tcmu-design.txt -- Just a thought, Simon Farnsworth signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Sex, 2015-05-29 at 09:28 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 9:19 AM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 08:54 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. This is a good subject for RPMFusion and all his kmods ... , but I really don't have time to think about it . In Ask we got examples of kmods signed for VirtualBox under Sercure Boot : https://ask.fedoraproject.org/en/question/68285/best-way-to-install-virtualbox/?answer=68413#post-id-68413 https://ask.fedoraproject.org/en/question/34470/virtual-box-on-fedora-19-fails-to-start-a-vm/?answer=59222#post-id-59222 Seems possible ship kernel modules on the fly since fedora package kernel also does it (it seems), I read that somewhere. Er... no we don't. The kernel package provides all it's modules already built. It doesn't build any on the fly after it is installed. I'm not sure where you read that. Sorry, I meant, the kernel package sign on the fly (the kernel modules) ? , that what we need, we need build a package and sign kernel modules on that build . josh Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Fri, May 29, 2015 at 11:57 AM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 09:28 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 9:19 AM, Sérgio Basto ser...@serjux.com wrote: On Sex, 2015-05-29 at 08:54 -0400, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. This is a good subject for RPMFusion and all his kmods ... , but I really don't have time to think about it . In Ask we got examples of kmods signed for VirtualBox under Sercure Boot : https://ask.fedoraproject.org/en/question/68285/best-way-to-install-virtualbox/?answer=68413#post-id-68413 https://ask.fedoraproject.org/en/question/34470/virtual-box-on-fedora-19-fails-to-start-a-vm/?answer=59222#post-id-59222 Seems possible ship kernel modules on the fly since fedora package kernel also does it (it seems), I read that somewhere. Er... no we don't. The kernel package provides all it's modules already built. It doesn't build any on the fly after it is installed. I'm not sure where you read that. Sorry, I meant, the kernel package sign on the fly (the kernel modules) ? , that what we need, we need build a package and sign kernel modules on that build . Ah, yes. The kernel modules are signed using an auto-generated cert during the kernel build. However, that doesn't help third party modules at all. The auto-generated cert is discarded when the kernel package build completes and isn't available for use outside of the koji buildroot for that specific kernel build. So at the time the kernel package is installed, the modules are already signed but the cert that was used is long since deleted. If one were to install kernel-devel and rebuild a module, it would auto-generate a new cert and use that to sign, but the installed kernel doesn't trust that cert. That is why David's plan, while complicated, is necessary. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/05/15 17:04, Simon Farnsworth wrote: On Friday 29 May 2015 15:24:24 David Sommerseth wrote: On 28/05/15 23:03, David Smith wrote: snip But really the best solution here is to get the mhvtl kernel module upstream. Agreed, but I'm not sure how keen upstream kernel developers are to carry a driver for virtual tape devices. I've asked mhvtl upstream if that has been considered, but currently I'm not convinced that will happen any time soon. As a different route, if upstream are still active, have they considered using LIO's TCMU interface[1]? Combine this with tcm_loop to provide local access to the LIO SCSI targets, and it looks to provide the same featureset as mhvtl's kernel module, using existing kernel infrastructure. Note that I've not dived in deep enough to confirm that LIO is a competent solution here, but it looks like it provides the features mhvtl needs. [1] https://www.kernel.org/doc/Documentation/target/tcmu-design.txt Thanks, Simon! I'll check up on that! I've not yet dug deep enough into how the tape library is fully managed on the lower levels (I'm still learning about how to make use of it). But if this can replace the mhvtl kernel module, that could perhaps simplify some of the work. Very simply explained: mhvtl generates /dev/mhvtl device nodes which is acting like tape robots. And the user space tools mhvtl provides is to link virtual tape drives/robots (via specific device nodes) to files on a file system. Then you can use ordinary tape tools (mt, mtx, backup tools understanding tape drives, etc) to store data in these files ... so the clue here is virtual tapes. If LIO/TCM can provide such support, then this might be a better solution. But thanks a lot for the heads up! - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVogsgACgkQIIWEatLf4Hc9FgCdEqyZ7gf0/sHFtQh2VzP/ujQF cfUAoIn9xKetfbvHAtxOe31l8dZ5g44P =ruwp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 05/28/2015 10:26 AM, David Sommerseth wrote: ... stuff deleted ... Any thoughts or comments to this approach? Anyone got a better idea? Your process looks reasonable. 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. Systemtap has a similar problem. By definition, we compile kernel modules and still need to work on a secure boot system. To solve it, we automated the process you outlined above and added it to our existing compile server functionality. On a client machine you ask for a systemtap script to run, and behind the scenes the script gets shipped off to a compile server that has a matching kernel devel environment and matching MOKs. The signed module gets shipped back to the client system and run. The advantage we have here is that if you have lots of client systems, none of them have the private MOK key installed on them - only the server has the private key(s). We only pass around public key fingerprints. 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! Systemtap's solution is probably pretty specific to ourselves, but the general idea (and perhaps some code) could certainly be borrowed. But really the best solution here is to get the mhvtl kernel module upstream. -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: 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. 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 [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! 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 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? 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 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! 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 enabled. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
