On Thu, Apr 7, 2022 at 9:20 AM Simo Sorce simo@redhat.com wrote:
On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote:
On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes jmforbes@linuxtx.org wrote:
Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all indicate Apple and Microsoft trust the driver itself. It is trusting the providence of the blob, in order to achieve an overall safer ecosystem for their users.
We either want users with NVIDIA hardware to be inside the Secure Boot fold or we don't. I want them in the fold *despite* the driver that needs signing is proprietary. That's a better user experience across the board, including the security messaging is made consistent. The existing policy serves no good at all and is double talk. If we really care about security more than ideological worry, we'd sign the driver.
At the very least, it would require that Fedora have a separate key that is trusted and not the same one used for shim/grub/kernel.
If Fedora is going to sign it, rather than improving the local signing experience, absolutely it should be signed with a separate key. The design should assume a revocation is going to happen at some point.
We certainly aren't proposing that we use the standard Fedora keys to sign a binary blob that runs in kernel space from a company who was most recently hacked last month?
No way.
I don't think there's a mechanism for it, but I'd prefer Fedora sign the 3rd party's key rather than their binary. Maybe it's a small distinction at the end of the day.
We have not set up an infrastructure for it, but in all honesty, there is no technical reason that any 3rd party repository building and packaging the driver could not have done such a thing a couple of years ago. The mechanism has been there, pesign can sign modules. Now, asking Fedora to trust that key is a different issue, but users have to reboot after installing the nvidia drivers anyway, so clicking to accept the key isn't too much of a hurdle to jump through at that point.
There is potentially an even easier solution. Ideally dkms (or whatever) could simply generate a key, sign the module and manage to get the public key in the right place so that the module can be verified. But this is hard work I guess, and nobody cares about Secure Boot enough to do it?
This has been done for a while. However, there are issues.
The lack of ability to manage it in a non-interactive fashion, or even fully from the desktop UX because of having to deal with firmware key storage is a huge problem. But even if you get past that, there are problems where there isn't enough memory on the firmware flash storage for another key. This is one of the reasons why the SBAT strategy was devised for Secure Boot: running out of space for certs in firmware is a very real problem that people want to avoid.
This is why an OS-level keyring for these things is needed: it allows us to scope it to the operating system (like Windows does), allows unique keys to be easily managed, and makes it easy to rotate them without worrying about causing problems.
-- 真実はいつも一つ！/ Always, there's only one truth!