| Message ID | 840433bc93a58d6dfc4d96c34c0c3b158a0e669d.1644953683.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Unifrom keyring support across architectures and functions | expand |
[Cc'ing Eric Snowberg] Hi Michal, On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > adds support for use of platform keyring in kexec verification but > support for modules is missing. > > Add support for verification of modules with keys from platform keyring > as well. Permission for loading the pre-OS keys onto the "platform" keyring and using them is limited to verifying the kexec kernel image, nothing else. FYI, Eric Snowberg's initial patch set titled "[PATCH v10 0/8] Enroll kernel keys thru MOK" is queued in Jarkko's git repo to be usptreamed. A subsequent patch set is expected.
Hello, On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > [Cc'ing Eric Snowberg] > > Hi Michal, > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > adds support for use of platform keyring in kexec verification but > > support for modules is missing. > > > > Add support for verification of modules with keys from platform keyring > > as well. > > Permission for loading the pre-OS keys onto the "platform" keyring and > using them is limited to verifying the kexec kernel image, nothing > else. Why is the platform keyring limited to kexec, and nothing else? It should either be used for everything or for nothing. You have the option to compile it in and then it should be used, and the option to not compile it in and then it cannot be used. There are two basic use cases: (1) there is a vendor key which is very hard to use so you sign something small and simple like shim with the vendor key, and sign your kernel and modules with your own key that's typically enrolled with shim MOK, and built into the kernel. (2) you import your key into the firmware, and possibly disable the vendor key. You can load the kernel directly without shim, and then your signing key is typically in the platform keyring and built into the kernel. In neither case do I see any reason to use some keyrings for kexec and other keyrings for modules. Thanks Michal
On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote: > Hello, > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > [Cc'ing Eric Snowberg] > > > > Hi Michal, > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > adds support for use of platform keyring in kexec verification but > > > support for modules is missing. > > > > > > Add support for verification of modules with keys from platform keyring > > > as well. > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > using them is limited to verifying the kexec kernel image, nothing > > else. > > Why is the platform keyring limited to kexec, and nothing else? > > It should either be used for everything or for nothing. You have the > option to compile it in and then it should be used, and the option to > not compile it in and then it cannot be used. > > There are two basic use cases: > > (1) there is a vendor key which is very hard to use so you sign > something small and simple like shim with the vendor key, and sign your > kernel and modules with your own key that's typically enrolled with shim > MOK, and built into the kernel. > > (2) you import your key into the firmware, and possibly disable the > vendor key. You can load the kernel directly without shim, and then your > signing key is typically in the platform keyring and built into the > kernel. > > In neither case do I see any reason to use some keyrings for kexec and > other keyrings for modules. When building your own kernel there isn't a problem. Additional keys may be built into the kernel image, which are loaded onto the ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally different keys are used for signing the kernel image and kernel modules. Kernel modules can be signed by the build time ephemeral kernel module signing key, which is built into the kernel and automatically loaded onto the ".builtin_trusted_keys" keyring. Similarly distros build the kernel module signing key into the kernel, which is built into the kernel and loaded onto the ".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the ".platform" keyring, kexec may verify the distro or other signed kernel images.
On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote: > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote: > > Hello, > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > [Cc'ing Eric Snowberg] > > > > > > Hi Michal, > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > adds support for use of platform keyring in kexec verification but > > > > support for modules is missing. > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > as well. > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > using them is limited to verifying the kexec kernel image, nothing > > > else. > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > It should either be used for everything or for nothing. You have the > > option to compile it in and then it should be used, and the option to > > not compile it in and then it cannot be used. > > > > There are two basic use cases: > > > > (1) there is a vendor key which is very hard to use so you sign > > something small and simple like shim with the vendor key, and sign your > > kernel and modules with your own key that's typically enrolled with shim > > MOK, and built into the kernel. > > > > (2) you import your key into the firmware, and possibly disable the > > vendor key. You can load the kernel directly without shim, and then your > > signing key is typically in the platform keyring and built into the > > kernel. > > > > In neither case do I see any reason to use some keyrings for kexec and > > other keyrings for modules. > > When building your own kernel there isn't a problem. Additional keys > may be built into the kernel image, which are loaded onto the > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally > different keys are used for signing the kernel image and kernel That's actually not normal. > modules. Kernel modules can be signed by the build time ephemeral > kernel module signing key, which is built into the kernel and > automatically loaded onto the ".builtin_trusted_keys" keyring. Right, there is this advice to use ephemeral key to sign modules. I don't think that's a sound advice in general. It covers only the special case when you build the kernel once, only rebuild the whole kernel and never just one module, don't use any 3rd party module, don't bother signing firmware (I am not sure that is supported right now but if you are into integrity and stuff you can see that it makes sense to sign it, too). And you need to manage the key you use for the kernel signing, anyway. Sure, you could use the same ephemeral key as for the modules, enroll it, and shred it but then it is NOT a key different from the one you use for modules. Or you could maintain a long-lived key for the kernel, but if you do I do NOT see any reason to not use it also for modules, in-tree and out-of-tree. > Similarly distros build the kernel module signing key into the kernel, > which is built into the kernel and loaded onto the > ".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the > ".platform" keyring, kexec may verify the distro or other signed > kernel images. Which are signed by the same key as the modules so there is no reason to load the platform key at all. I don't think loading shim with kexec is supported. Thanks Michal
On Wed, Feb 16, 2022 at 11:56:45AM +0100, Michal Suchánek wrote: > On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote: > > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote: > > > Hello, > > > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > > [Cc'ing Eric Snowberg] > > > > > > > > Hi Michal, > > > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > > adds support for use of platform keyring in kexec verification but > > > > > support for modules is missing. > > > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > > as well. > > > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > > using them is limited to verifying the kexec kernel image, nothing > > > > else. > > > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > > > It should either be used for everything or for nothing. You have the > > > option to compile it in and then it should be used, and the option to > > > not compile it in and then it cannot be used. > > > > > > There are two basic use cases: > > > > > > (1) there is a vendor key which is very hard to use so you sign > > > something small and simple like shim with the vendor key, and sign your > > > kernel and modules with your own key that's typically enrolled with shim > > > MOK, and built into the kernel. > > > > > > (2) you import your key into the firmware, and possibly disable the > > > vendor key. You can load the kernel directly without shim, and then your > > > signing key is typically in the platform keyring and built into the > > > kernel. > > > > > > In neither case do I see any reason to use some keyrings for kexec and > > > other keyrings for modules. > > > > When building your own kernel there isn't a problem. Additional keys > > may be built into the kernel image, which are loaded onto the > > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally > > different keys are used for signing the kernel image and kernel > > That's actually not normal. > > > modules. Kernel modules can be signed by the build time ephemeral > > kernel module signing key, which is built into the kernel and > > automatically loaded onto the ".builtin_trusted_keys" keyring. > > Right, there is this advice to use ephemeral key to sign modules. > > I don't think that's a sound advice in general. It covers only the > special case when you build the kernel once, only rebuild the whole > kernel and never just one module, don't use any 3rd party module, don't > bother signing firmware (I am not sure that is supported right now but > if you are into integrity and stuff you can see that it makes sense to > sign it, too). And don't forget signing ramdisk which you typically don't build only once at kernel build time. > > And you need to manage the key you use for the kernel signing, anyway. > Sure, you could use the same ephemeral key as for the modules, enroll > it, and shred it but then it is NOT a key different from the one you use > for modules. > > Or you could maintain a long-lived key for the kernel, but if you do I > do NOT see any reason to not use it also for modules, in-tree and > out-of-tree. > > > Similarly distros build the kernel module signing key into the kernel, > > which is built into the kernel and loaded onto the > > ".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the > > ".platform" keyring, kexec may verify the distro or other signed > > kernel images. > > Which are signed by the same key as the modules so there is no reason to > load the platform key at all. I don't think loading shim with kexec is > supported. > > Thanks > > Michal
On Wed, 2022-02-16 at 11:56 +0100, Michal Suchánek wrote: > On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote: > > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote: > > > Hello, > > > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > > [Cc'ing Eric Snowberg] > > > > > > > > Hi Michal, > > > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > > adds support for use of platform keyring in kexec verification but > > > > > support for modules is missing. > > > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > > as well. > > > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > > using them is limited to verifying the kexec kernel image, nothing > > > > else. > > > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > > > It should either be used for everything or for nothing. You have the > > > option to compile it in and then it should be used, and the option to > > > not compile it in and then it cannot be used. > > > > > > There are two basic use cases: > > > > > > (1) there is a vendor key which is very hard to use so you sign > > > something small and simple like shim with the vendor key, and sign your > > > kernel and modules with your own key that's typically enrolled with shim > > > MOK, and built into the kernel. > > > > > > (2) you import your key into the firmware, and possibly disable the > > > vendor key. You can load the kernel directly without shim, and then your > > > signing key is typically in the platform keyring and built into the > > > kernel. > > > > > > In neither case do I see any reason to use some keyrings for kexec and > > > other keyrings for modules. > > > > When building your own kernel there isn't a problem. Additional keys > > may be built into the kernel image, which are loaded onto the > > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally > > different keys are used for signing the kernel image and kernel > > That's actually not normal. > > > modules. Kernel modules can be signed by the build time ephemeral > > kernel module signing key, which is built into the kernel and > > automatically loaded onto the ".builtin_trusted_keys" keyring. > > Right, there is this advice to use ephemeral key to sign modules. > > I don't think that's a sound advice in general. It covers only the > special case when you build the kernel once, only rebuild the whole > kernel and never just one module, don't use any 3rd party module, don't > bother signing firmware (I am not sure that is supported right now but > if you are into integrity and stuff you can see that it makes sense to > sign it, too). > > And you need to manage the key you use for the kernel signing, anyway. > Sure, you could use the same ephemeral key as for the modules, enroll > it, and shred it but then it is NOT a key different from the one you use > for modules. > > Or you could maintain a long-lived key for the kernel, but if you do I > do NOT see any reason to not use it also for modules, in-tree and > out-of-tree. If signing ALL kernel modules, in-tree and out-of-tree, with the same key as the kernel image, is your real intention, then by all means write a complete patch description with the motivation for why kernel module signatures need to be verified against this one pre-OS key stored only in the platform keyring. Such a major change like this shouldn't be buried here. Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys thru MOK patch set" patch set [1], as previously mentioned, which is queued to be upstreamed by Jarkko. It loads MOK keys onto the '.machine' keyring, which is linked to the '.secondary_trusted_keys" keyring. A subsequent patch set will enable IMA support. [1] https://lore.kernel.org/lkml/20220126025834.255493-1-eric.snowberg@oracle.com/
On Wed, Feb 16, 2022 at 06:58:51AM -0500, Mimi Zohar wrote: > On Wed, 2022-02-16 at 11:56 +0100, Michal Suchánek wrote: > > On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote: > > > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote: > > > > Hello, > > > > > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > > > [Cc'ing Eric Snowberg] > > > > > > > > > > Hi Michal, > > > > > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > > > adds support for use of platform keyring in kexec verification but > > > > > > support for modules is missing. > > > > > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > > > as well. > > > > > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > > > using them is limited to verifying the kexec kernel image, nothing > > > > > else. > > > > > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > > > > > It should either be used for everything or for nothing. You have the > > > > option to compile it in and then it should be used, and the option to > > > > not compile it in and then it cannot be used. > > > > > > > > There are two basic use cases: > > > > > > > > (1) there is a vendor key which is very hard to use so you sign > > > > something small and simple like shim with the vendor key, and sign your > > > > kernel and modules with your own key that's typically enrolled with shim > > > > MOK, and built into the kernel. > > > > > > > > (2) you import your key into the firmware, and possibly disable the > > > > vendor key. You can load the kernel directly without shim, and then your > > > > signing key is typically in the platform keyring and built into the > > > > kernel. > > > > > > > > In neither case do I see any reason to use some keyrings for kexec and > > > > other keyrings for modules. > > > > > > When building your own kernel there isn't a problem. Additional keys > > > may be built into the kernel image, which are loaded onto the > > > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally > > > different keys are used for signing the kernel image and kernel > > > > That's actually not normal. > > > > > modules. Kernel modules can be signed by the build time ephemeral > > > kernel module signing key, which is built into the kernel and > > > automatically loaded onto the ".builtin_trusted_keys" keyring. > > > > Right, there is this advice to use ephemeral key to sign modules. > > > > I don't think that's a sound advice in general. It covers only the > > special case when you build the kernel once, only rebuild the whole > > kernel and never just one module, don't use any 3rd party module, don't > > bother signing firmware (I am not sure that is supported right now but > > if you are into integrity and stuff you can see that it makes sense to > > sign it, too). > > > > And you need to manage the key you use for the kernel signing, anyway. > > Sure, you could use the same ephemeral key as for the modules, enroll > > it, and shred it but then it is NOT a key different from the one you use > > for modules. > > > > Or you could maintain a long-lived key for the kernel, but if you do I > > do NOT see any reason to not use it also for modules, in-tree and > > out-of-tree. > > If signing ALL kernel modules, in-tree and out-of-tree, with the same > key as the kernel image, is your real intention, then by all means Why would you sign them with different keys, specifically? For out of tree modules, sure. But that's an ADDITIONAL key, not REMOVAL of a key. > write a complete patch description with the motivation for why kernel > module signatures need to be verified against this one pre-OS key > stored only in the platform keyring. Such a major change like this > shouldn't be buried here. No, in my book it does not make sense to verify anything against the pre-os key at all in the common case. However, if you do verify the kernel against the pre-os key it does not make sense to not verify modules against the pre-os key. There is no sense using different key for kernel and modules. They are both built in the same environment with access to same the keys. > Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys > thru MOK patch set" patch set [1], as previously mentioned, which is > queued to be upstreamed by Jarkko. It loads MOK keys onto the > '.machine' keyring, which is linked to the '.secondary_trusted_keys" > keyring. A subsequent patch set will enable IMA support. I don't really care how many keyrings there are. What I care about is that they are used conssitently. Thanks Michal
How's this series going? Did you and Mimi sort things out? Either way, just wanted to let you kow you can base your changes on modules-testing [0] if you want to resubmit for v5.19 (v5.18 will be too late already). Once testing is done what is on modules-testing will go to modules-next for testing for v5.19. There are no changes planned for v5.18 other than fixes and so far there are none. [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing Luis
Hi Luis, On Tue, 2022-03-22 at 10:37 -0700, Luis Chamberlain wrote: > How's this series going? Did you and Mimi sort things out? Either way, > just wanted to let you kow you can base your changes on modules-testing > [0] if you want to resubmit for v5.19 (v5.18 will be too late already). > Once testing is done what is on modules-testing will go to modules-next > for testing for v5.19. There are no changes planned for v5.18 other than > fixes and so far there are none. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing The "platform" keyring was upstreamed specifically to verify the kexec kernel image. Orginally it contained only the UEFI db keys, but the MOK keys were later added as well. Any other usage of the "platform" is not planned. To allow end users to sign their own kernel modules, executables, or any other file, Eric Snowberg is working on a patch set to only load the MOK CA keys onto the ".machine" keyring, which is linked to the "secondary" keyring[1]. Verifying kernel modules based on certificates signed by a MOK CA will then be possible. thanks, Mimi [1] https://lore.kernel.org/all/20220301173651.3435350-1-eric.snowberg@oracle.com/
Hi Mimi, Sorry for bother you for this old topic. On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote: > Hello, > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > [Cc'ing Eric Snowberg] > > > > Hi Michal, > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > adds support for use of platform keyring in kexec verification but > > > support for modules is missing. > > > > > > Add support for verification of modules with keys from platform keyring > > > as well. > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > using them is limited to verifying the kexec kernel image, nothing > > else. > > Why is the platform keyring limited to kexec, and nothing else? > > It should either be used for everything or for nothing. You have the > option to compile it in and then it should be used, and the option to > not compile it in and then it cannot be used. > > There are two basic use cases: > > (1) there is a vendor key which is very hard to use so you sign > something small and simple like shim with the vendor key, and sign your > kernel and modules with your own key that's typically enrolled with shim > MOK, and built into the kernel. > > (2) you import your key into the firmware, and possibly disable the > vendor key. You can load the kernel directly without shim, and then your > signing key is typically in the platform keyring and built into the > kernel. > In the second use case, if user can enroll their own key to db either before or after hardware shipping. And they don't need shim because they removed Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to them for trusting db keys for verifying kernel module, or for IMA (using CA in db)? In the above use case for distro, partner doesn't need to re-compiler distro kernel. They just need to re-sign distro kernel and modules. Which means that the partner trusted distro. Then the partner's key in db can be used to verify kernel image and also kernel module without shim involve. Regards Joey Lee
On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote: Hi Joey, > Hi Mimi, > > Sorry for bother you for this old topic. Cc'ing Luis the kernel modules maintainer. > > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote: > > Hello, > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > [Cc'ing Eric Snowberg] > > > > > > Hi Michal, > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > adds support for use of platform keyring in kexec verification but > > > > support for modules is missing. > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > as well. > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > using them is limited to verifying the kexec kernel image, nothing > > > else. > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > It should either be used for everything or for nothing. You have the > > option to compile it in and then it should be used, and the option to > > not compile it in and then it cannot be used. > > > > There are two basic use cases: > > > > (1) there is a vendor key which is very hard to use so you sign > > something small and simple like shim with the vendor key, and sign your > > kernel and modules with your own key that's typically enrolled with shim > > MOK, and built into the kernel. > > > > (2) you import your key into the firmware, and possibly disable the > > vendor key. You can load the kernel directly without shim, and then your > > signing key is typically in the platform keyring and built into the > > kernel. > > > > In the second use case, if user can enroll their own key to db either before > or after hardware shipping. And they don't need shim because they removed > Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to > them for trusting db keys for verifying kernel module, or for IMA (using CA > in db)? > > In the above use case for distro, partner doesn't need to re-compiler distro > kernel. They just need to re-sign distro kernel and modules. Which means > that the partner trusted distro. Then the partner's key in db can be used to > verify kernel image and also kernel module without shim involve. From what I understand, distros don't want customers resigning their kernels. If they did, then they could have enabled the CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the "builtin" keyring, and anything signed by those keys could be loaded onto the secondary keyring. (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE would need to be fixed/updated.) We've gone through "what if" scenarios before. My response then, as now, is post it as a patch with the real motivation for such a change. thanks, Mimi
Hello, On Mon, Mar 28, 2022 at 09:28:14AM -0400, Mimi Zohar wrote: > On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote: > > Hi Joey, > > > Hi Mimi, > > > > Sorry for bother you for this old topic. > > Cc'ing Luis the kernel modules maintainer. > > > > > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote: > > > Hello, > > > > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > > > > [Cc'ing Eric Snowberg] > > > > > > > > Hi Michal, > > > > > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > > > > adds support for use of platform keyring in kexec verification but > > > > > support for modules is missing. > > > > > > > > > > Add support for verification of modules with keys from platform keyring > > > > > as well. > > > > > > > > Permission for loading the pre-OS keys onto the "platform" keyring and > > > > using them is limited to verifying the kexec kernel image, nothing > > > > else. > > > > > > Why is the platform keyring limited to kexec, and nothing else? > > > > > > It should either be used for everything or for nothing. You have the > > > option to compile it in and then it should be used, and the option to > > > not compile it in and then it cannot be used. > > > > > > There are two basic use cases: > > > > > > (1) there is a vendor key which is very hard to use so you sign > > > something small and simple like shim with the vendor key, and sign your > > > kernel and modules with your own key that's typically enrolled with shim > > > MOK, and built into the kernel. > > > > > > (2) you import your key into the firmware, and possibly disable the > > > vendor key. You can load the kernel directly without shim, and then your > > > signing key is typically in the platform keyring and built into the > > > kernel. > > > > > > > In the second use case, if user can enroll their own key to db either before > > or after hardware shipping. And they don't need shim because they removed > > Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to > > them for trusting db keys for verifying kernel module, or for IMA (using CA > > in db)? > > > > In the above use case for distro, partner doesn't need to re-compiler distro > > kernel. They just need to re-sign distro kernel and modules. Which means > > that the partner trusted distro. Then the partner's key in db can be used to > > verify kernel image and also kernel module without shim involve. > > From what I understand, distros don't want customers resigning their > kernels. If they did, then they could have enabled the > CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the > "builtin" keyring, and anything signed by those keys could be loaded > onto the secondary keyring. (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE > would need to be fixed/updated.) You don't need to re-sign. You can just import the distro key into the firmware. > > We've gone through "what if" scenarios before. My response then, as > now, is post it as a patch with the real motivation for such a change. Then that's what this does. Both modules and kernel run on ring0 so there is no practical distinction. For consistency verify both with the same keys. Either way if there should be a disctinction it should be explicit, not implicit. That is each option that imports keys should crate a basic keyring that just has keys, and we should have 'kexec' and 'module' keyrings that do not have keys, only link the keyrings that import keys from some specific source. All of them by default but you can adjust this in defconfigs depending on platform-typical usage. Contrast to that the current 'secondary' keyring that randomly links some key sources and not others, is used in some kexec implementations and not others. Also if you list the keys in it do you get the keys dynamically added at runtime, or also all the keys on the linked keyrings? Whatever you get is misleading and unclear. Thanks Michal
> On Mar 28, 2022, at 4:15 AM, joeyli <jlee@suse.com> wrote: > > Hi Mimi, > > Sorry for bother you for this old topic. > > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote: >> Hello, >> >> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: >>> [Cc'ing Eric Snowberg] >>> >>> Hi Michal, >>> >>> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: >>>> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") >>>> adds support for use of platform keyring in kexec verification but >>>> support for modules is missing. >>>> >>>> Add support for verification of modules with keys from platform keyring >>>> as well. >>> >>> Permission for loading the pre-OS keys onto the "platform" keyring and >>> using them is limited to verifying the kexec kernel image, nothing >>> else. >> >> Why is the platform keyring limited to kexec, and nothing else? >> >> It should either be used for everything or for nothing. You have the >> option to compile it in and then it should be used, and the option to >> not compile it in and then it cannot be used. >> >> There are two basic use cases: >> >> (1) there is a vendor key which is very hard to use so you sign >> something small and simple like shim with the vendor key, and sign your >> kernel and modules with your own key that's typically enrolled with shim >> MOK, and built into the kernel. >> >> (2) you import your key into the firmware, and possibly disable the >> vendor key. You can load the kernel directly without shim, and then your >> signing key is typically in the platform keyring and built into the >> kernel. >> > > In the second use case, if user can enroll their own key to db either before > or after hardware shipping. And they don't need shim because they removed > Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to > them for trusting db keys for verifying kernel module, or for IMA (using CA > in db)? > > In the above use case for distro, partner doesn't need to re-compiler distro > kernel. They just need to re-sign distro kernel and modules. Which means > that the partner trusted distro. Then the partner's key in db can be used to > verify kernel image and also kernel module without shim involve. If shim is used, the new machine keyring can be used to solve this problem. This pull request [1] allows additional certificates to be loaded into the MOKList without going through MokManager. Have the end-user/partner create a shim_certificate.efi containing their key. Then sign it with their DB key. When shim boots, it will validate shim_certificate.efi against the DB key and load the key contained within it into the MOKList. Now both module and kernel validation can be performed with this key, since it is contained within the machine keyring. [1] https://github.com/rhboot/shim/pull/446
Hello, On Mon, Mar 28, 2022 at 02:44:30PM +0000, Eric Snowberg wrote: > > > > On Mar 28, 2022, at 4:15 AM, joeyli <jlee@suse.com> wrote: > > > > Hi Mimi, > > > > Sorry for bother you for this old topic. > > > > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote: > >> Hello, > >> > >> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > >>> [Cc'ing Eric Snowberg] > >>> > >>> Hi Michal, > >>> > >>> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > >>>> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > >>>> adds support for use of platform keyring in kexec verification but > >>>> support for modules is missing. > >>>> > >>>> Add support for verification of modules with keys from platform keyring > >>>> as well. > >>> > >>> Permission for loading the pre-OS keys onto the "platform" keyring and > >>> using them is limited to verifying the kexec kernel image, nothing > >>> else. > >> > >> Why is the platform keyring limited to kexec, and nothing else? > >> > >> It should either be used for everything or for nothing. You have the > >> option to compile it in and then it should be used, and the option to > >> not compile it in and then it cannot be used. > >> > >> There are two basic use cases: > >> > >> (1) there is a vendor key which is very hard to use so you sign > >> something small and simple like shim with the vendor key, and sign your > >> kernel and modules with your own key that's typically enrolled with shim > >> MOK, and built into the kernel. > >> > >> (2) you import your key into the firmware, and possibly disable the > >> vendor key. You can load the kernel directly without shim, and then your > >> signing key is typically in the platform keyring and built into the > >> kernel. > >> > > > > In the second use case, if user can enroll their own key to db either before > > or after hardware shipping. And they don't need shim because they removed > > Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to > > them for trusting db keys for verifying kernel module, or for IMA (using CA > > in db)? > > > > In the above use case for distro, partner doesn't need to re-compiler distro > > kernel. They just need to re-sign distro kernel and modules. Which means > > that the partner trusted distro. Then the partner's key in db can be used to > > verify kernel image and also kernel module without shim involve. > > If shim is used, the new machine keyring can be used to solve this problem. > This pull request [1] allows additional certificates to be loaded into the MOKList > without going through MokManager. Have the end-user/partner create a > shim_certificate.efi containing their key. Then sign it with their DB key. When > shim boots, it will validate shim_certificate.efi against the DB key and load the > key contained within it into the MOKList. Now both module and kernel validation > can be performed with this key, since it is contained within the machine keyring. And why would you go through that when your platform keyring already has the key and you don't need shim for anything? This sounds a lot like "I have a hammer and all these look like nails" thinking. Sure, there is use for the machine keyring in the case you need it and have it regardless of the kernel making any use of it for anything. Artifically adding it because the kernel fails to work with the platform keyring sounds backwards, though. Thanks Michal
diff --git a/kernel/module_signing.c b/kernel/module_signing.c index 8723ae70ea1f..5e1624294874 100644 --- a/kernel/module_signing.c +++ b/kernel/module_signing.c @@ -38,8 +38,14 @@ int mod_verify_sig(const void *mod, struct load_info *info) modlen -= sig_len + sizeof(ms); info->len = modlen; - return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, - VERIFY_USE_SECONDARY_KEYRING, - VERIFYING_MODULE_SIGNATURE, - NULL, NULL); + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, + VERIFY_USE_SECONDARY_KEYRING, + VERIFYING_MODULE_SIGNATURE, + NULL, NULL); + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, + VERIFY_USE_PLATFORM_KEYRING, + VERIFYING_MODULE_SIGNATURE, + NULL, NULL); + return ret; }
Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") adds support for use of platform keyring in kexec verification but support for modules is missing. Add support for verification of modules with keys from platform keyring as well. Fixes: 219a3e8676f3 ("integrity, KEYS: add a reference to platform keyring") Cc: linux-modules@vger.kernel.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: stable@kernel.org Signed-off-by: Michal Suchanek <msuchanek@suse.de> --- kernel/module_signing.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)