Nvidia Driver Installation with Secure Boot Support
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Nvidia Drivers have been removed from GNOME Software because it didn’t support Secure Boot which is increasingly often enabled. This change brings the option back with Secure Boot supported.
The goal is this change is to provide an easy way to install Nvidia drivers in Fedora Workstation. It was removed from GNOME Software because the original mechanism didn’t support Secure Boot. When users installed the drivers with Secure Boot enabled, they could not boot the OS. What we’re doing this time is using mokutil to create a key for the user to self-sign the drivers. When installing the drivers, the user is asked to provide a password for the key. On the next reboot the user is presented with the mokutil interface to enroll the key.
The Nvidia drivers are necessary not only for gaming, but especially for CUDA and AI/LLM workloads. The Nvidia drivers can’t be part of Fedora because of their license, but Fedora should offer an easy installation of them to stay relevant in the respective fields.
Scope
Proposal Owners: The feature will be implemented in GNOME Software 47 and will be shipped in the gnome-software package in Fedora Linux 41.
Other Developers: No work required from other Fedora developers. The only requirement outside of the scope of the proposal owners is to reintroduce AppStream metadata into the Nvidia driver repo on RPMFusion.org.
Release Engineering:
Policies and Guidelines:
Trademark approval:
Alignment with Community Initiatives:
Upgrade/compatibility impact
No impact is expected.
How To Test
Open GNOME Software.
Search for “nvidia”.
Choose the Nvidia driver, click Install and follow the prompts.
Reboot and enroll the self-signing key in the mokutil tool following <>
The OS should boot up with the Nvidia driver enabled.
User Experience
This change aims to improve user experience of installing the proprietary Nvidia driver.
Contingency Plan
If the feature is not implemented on time for Fedora Linux 41, we can simply remove AppStream metadata from the Nvidia driver repo and the driver will not show up in GNOME Software like in Fedora Linux 40.
Documentation
The GNOME Software part is intuitive and doesn’t require documentation. The mokutil part is less intuitive and will be documented in the Fedora Workstation section on docs.fedoraproject.org. The docs will be published when the feature lands in Fedora Linux 41.
If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.
We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.
Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.
The details matter here, as they can potentially affect the level of protection offered by SecureBoot.
IIUC from the linked change, with the new workflow, the first time the user requests installation of an out of tree kmod, like Nvidia, they will be prompted to enter a password. A public+private keypair will be created and IIUC permanently stored in the OS at /etc/pki/akmods/{cert,private}, and the public cert setup for enrollment with shim with a one-time-only passwd confirmation. On reboot they’ll be prompted by shim to enter this one-time password, when shim verifies the requested installation of the MOK cert. This is good as it avoids a malicious process on the host from automating install of a MOK without an explicit user approval step.
Thereafter every time there is either a new kmod to be installed, or any update of an existing kmod, IIUC the existing private key will be used to sign this kmod, and NO human interactive prompting will be required. This feels bad for the security of the machine, as it seems to suggest that a rootkit in the OS can now use the MOK private key to get any kmod at all to run with an approved SecureBoot signature, with no user approval required.
If we consider the core purpose of SecureBoot is to prevent rootkits from compromising the boot flow, then haven’t we just null-ified SecureBoot’s purpose with this automation to the extent that the user might as well have just turned off SecureBoot in the FW ? Have I missed some detail that prevents a malicious OS process from using the MOK private component to sign arbitrary code ?
You are correct. Enrolling the key weakens secureboot’s effectiveness for as long as akmods are being used. If it’s extracted from storage (offline) or there’s privilege escalation (online), then any kernel modules can be signed and loaded by a bad actor. This is the price you have to pay for using off-tree kernel modules.
Using disk encryption partially mitigates by this issue by preventing an external threat from tampering with the MOK key. However, this doesn’t stop privilege escalation exploits.
IMHO offline disk tampering is rather a niche scenario by comparison with “Privilege escalation exploits” which are the primary threat that SecureBoot is/was intended to protect against. The change proposal makes no mention of how this approach significantly undermines the protection offerd by SecureBoot.
The proposed GUI where the user is prompted for a key also makes no mention of the security implications of taking this action. The descriptive text is
“Please provide a password for a newly generated machine owner key to be installed to authenticate %s and future custom drivers”
this gives the user the impression that there is authentication taking place on every future use of custom drivers, suggesting it would maintain the security benefits of SecureBoot. IMHO this is very misleading to the users.
I get that it is desirable to have a smooth way to use external drivers, but this feels like it is opening way too large of a hole.
That’s not the only possible alternative, there are many ways the problem could be approached, each with their own pros/cons. Perhaps what is proposed in this Change is still ultimately the best tradeoff, but saying this is the only solution other than upstreaming is not correct.
For example, there could be a specification for a location on disk where 3rd party YUM repos could place public key signing certs, to be loaded into shim, with an interactive user prompt. That would not involve having the private key on the installed system, and so the scope would be a limited to only allowing use of kmods signed by the owner of each respective 3rd party repo. I presume this would imply that that the repo has to issue new signed kmod builds for each new Fedora kernel update, so there are some problems to be concerned with, that might make it impractical. It is none the less an alternative option.
Sure, it’s not the only alternative, but keep in mind that this proposal simply implements a way to go through the steps users are currently instructed to follow graphically. I don’t believe this adds any additional risk compared to what the current status-quo is.
If the concern is the user being unaware that this reduces their device’s security, then that could be solved with a disclaimer in the UI.
The main trouble with providing pre-signed nvidia modules is that this would require a significant amount of resources.
If a third-party, like rpmfusion, for example, wanted to provide modules with their own signed key, then they’d need to track every single fedora kernel version, across every release, and create a nvidia-kmod for that specific kernel. This would be pretty difficult to manage when the kernel and nvidia driver are in completely different repositories.
I could only see this being viable if Fedora itself decided to open up an exception and decided to add the nvidia kernel module to official repos. Despite the fact there’s now an open-source variant of the kernel module, packaging policies prohibit off-tree kernel modules from being shipped.
I appreciate the concerns being raised here in the thread, but I want to point out that while this solution definitely reduces the trustworthiness of Secure Boot, it’s not really any worse than our general packaging policies. In fact, it’s a pretty great metaphor:
When we add a package to Fedora, it’s quite strictly reviewed. We have detailed packaging policies and require another packager in good standing to look through it and ensure that it’s permissible and properly packaged. After that, we do no follow-up on that package. We trust that the maintainer will continue to ship quality code from the package upstream and vet it for changes that might introduce risk. We (Fedora) signs every binary RPM, asserting trustworthiness.
This is fundamentally the same thing we’re doing with this change: the user will make a decision once at the beginning to validate (or not) that the nVidia drivers are safe and then allow them and all future versions on their system.
Yes, it’s a risk but I’d argue it’s no worse than updating any other package on the system.
That’s not what is happening here. The user is validating that any kmods on their machine are safe, no matter where those kmods came from (nvidia rpmfusion packages, or manually created kmods, or malicious kmods from a root kit), because any privileged process on the machine can use the MOK private key to sign arbitrary kmods forever more.
I’d rather see no Secure Boot support, vs seeing some insecure implementation for it on what’s supposed to be a security-focused distro. The alternative is for those people to disable Secure Boot, or manually handle it (presumably in a different non-private-key-sharing manner).
Any non-NVIDIA-related kmod being able to use the same private key in this implementation doesn’t sound secure.
I came to this thread thinking who could be against this, but the first post made no mention of that security concern.
I remember when LInux users used to recommend disabling Secure Boot. Windows 11 doesn’t enforce it. If a user chooses to deal with Secure Boot, I think they should be prepared to handle their decision properly with non-automated key signings and understand the process. Else, reboot → spam press some BIOS key → disable SB, and probably run into less issues overall beyond NVIDIA’s driver (no kernel lockdown/etc).
I’d definitely prefer to have a limited amount of security over none…
Even with the risk of keeping the MOK around the actual host device itself (privilege escalation), it still guarantees that no external tampering is possible. (when disk encryption is being used)
This proposal is miss-named as it only affects the workstation spin.
This could be added to anaconda so it was available for all fedora users.
I hope gnome-software adds some warnings about security.
I don’t get why this change is being added to gnome-software, the upstream merge request is only useful for redhat/fedora based distro’s.
Why are redhat developers wasting time on a solution that is only useful for about 30% of users?
This change should be implemented as an anaconda spoke to add mok key enrolment, adding it to the installer covers all users.
Ubuntu and other distro’s have mok enrolment in their installers.
If the approach, security wise, is to enroll a key permanently and keep it in /etc/pki/akmods, then doing so in Anaconda rather than gnome-software would seem to make sense to me, assuming Anaconda can reliably know that the user needs akmods drivers.
If the approach were to (for example) generate a new key for each akmods driver installation, then it couldn’t be done in Anaconda and would have to be done in gnome-software/KDE Discover. I’m not suggesting that approach, though; I don’t think it would buy any extra security, as the private key would still be on disk for a (shorter) period of time, readable by any privilege-escalated malicious process and hence available to make the malicious process persist.
As Leigh says, this means the feature becomes available to a wider audience. It also means it’s set up at a point closer to when Secure Boot is originally set up, so explaining the security tradeoffs to users may be a bit easier then.
It’s mentioned above once or twice, but let me say it again: the gnome-software change does not add any insecurity, in fact it’s a lame change, it only does what’s written in the README.secureboot. Note it’s the way akmods itself needs the things to be done, not the NVIDIA drivers, neither gnome-software. The only thing the gnome-software change does is that it brings the steps from the README.secureboot from command line into the GUI, to make it easier to enable the drivers for the regular users. If you want to blame security problems, then tell the akmods about it. If your point is “this is too easy”, then maybe you are right.
That is true from a strictly technical POV, however, gnome-software is making the decision to actively promote akmods as a solution to end users. If akmods is known to have insecure practices of storing private keys on host, then gnome-software is a facilitator in making the distro less secure by encouraging usage of akmods, and glossing over the insecurity such that users are not even aware of the consequences of their choices.
Summary
instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.