> From: Chris Murphy [mailto:lists@xxxxxxxxxxxxxxxxx] > Sent: Thursday, January 6, 2022 9:34 PM > Could this feature work with 3rd party kernel modules, in a UEFI > Secure Boot (and thus kernel lockdown) context? It could be possible to create a digest list of third-party kernel modules. However, in the current implementation, DIGLIM is not used as an alternative for kernel module verification. Theoretically it is possible, you could extract the digests of kernel modules from the signed RPM header and use those digests for verification. However, the trust problem remains. If your kernel does not trust the PGP key of the repository providing third-party modules, the kernel would refuse to access the RPM header. The user has to trust the additional key. Whether it is better to trust an external repository to adequately protect the private key used for signing, or to keep the private key in the system that would load the third-party kernel modules is a difficult decision, and probably each user would like to make that decision. Personally, I would find something like this acceptable. Currently, Fedora vouches for the source code of the packages that it provides, for building the source code correctly, and for adequately protecting the private key used to sign the packages. Fedora could provide an additional repository for which it does not vouch for what the software does on the system, but only that the source is reliable (e.g. the software is made by NVIDIA) and that the software is coming from that source. The key used to sign those packages could be embedded in the kernel (so that there are no problems verifying it from the boot loaded), but disabled by default. That key can be loaded upon user request (e.g. through an option in the kernel command line). In my opinion, the guarantees provided by such solution are much higher than using external repositories or having the private key in the same system that is going to use the third-party kernel modules. > Workstation working group is tracking this problem as > https://pagure.io/fedora-workstation/issue/155 > > If DIGLIM could be used for this use case, I further wonder whether > it's possible to have multiple signatures for different portions of a > kernel module? The purpose, is so NVIDIA can sign their proprietary > binary blob (because it's theirs, no one else's, and therefore they > should sign it). Next,either (a) Fedora (b) RPM Fusion (c) the user, > can sign the remainder of the kernel module (the parts that are open > source anyway). It's an open question who could or should sign > NVIDIA's key, to narrowly indicate trust. And also a mechanism for > revoking that trust without breaking everything else. The DIGLIM approach would be to have an additional user space parser that takes the NVIDIA blob as an input (it must be signed with a key that the kernel trusts) and that does some calculations to determine what the digest of the built kernel module will be. The additional parser will then upload the digest to the kernel. The real process of building the kernel module can be done in an untrusted way in user space. I don't see it too much viable. The complexity of the parser doing the calculations will be very high (maybe it needs to have logic from gcc). The main point is how to guarantee that the transformation from the NVIDIA blob to the kernel module is done right. To guarantee that for the local system, it would be necessary to enforce a heavy integrity policy (not only on the executables, but also on all the inputs used for the transformation). It is much easier if users trust a building infrastructure to do that. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
