On Di, 20.12.22 21:32, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > As someone whose day job involves working with teams who develop both > Windows and Linux drivers (and in the past, even macOS drivers!), I > can categorically say that Windows driver engineering processes are > way friendlier than Linux ones, precisely because Windows drivers are > deliberately not exposed to Secure Boot *at all*. Running development > versions of drivers just requires installing a development certificate > into the NT kernel certificate store. The equivalent process for Linux > is to load a custom secure boot certificate into firmware, which is > fraught with peril and potentially not even possible. This is a bit of a misrepresentation how this currently works. The Linux kernel populates its keyrings these days from both built-in keys and from those imported from uefi vars (both uefi db and mokutil stuff). So, yes, SecureBoot keys are imported into the kernel keyring, but they aren't the only thing. You can enroll your own via mokutil and the OS vendor can enroll by building them into the kernel. Neither of those two has much to do with firmware, i.e. there's no need to update the UEFI db, updating the mokutil efi vars is enough. > I cannot tell you how many times I've bricked a system by attempting > to load another cert only to find out there's not enough space and > the firmware didn't handle that well. Well, sure, space in the efi vars is limited. But christ, how many certs did you actually enroll via mokutil? (if you are working with local throw-away certs, then I guess it's just not build for that) I mean, sure, it would make sense of shim would be able to manage a keyring on a file in the ESP instead of purely via an efi var, but this massively raises the question of authenticating that. i.e. would require some TPM protection usually, but TPM from UEFI mode is not fun, since (except for PCR measurements) you have to roll the TPM communication yourself (or embedd a fill TPM stack, but thta's going to make shim even larger than it already is). I mean, file an RFE against shim. But this really has nothing to do with UKIs/sysext, we just use the same authentication mechanisms as before pretty much: UKIs are authenticated like any kernels, just as before, and sysext are authenticated via the same keyring as kmods basically. Hence there's nothing really new here when it comes to key management. If you have beef with how Linux manages the keys for authenticating kmods then bring that up with the kernel community, it has nothing to do with the way UKIs/sysext works. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
