Pcie_tegra194: module verification failed: signature and/or required key missing - tainting kernel

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

I am running the system using a modified rootfs on Orin NX. When checking the journalctl logs, I found the following error log included within:

pcie_tegra194: module verification failed: signature and/or required key missing - tainting kernel

However, PCIe appears to be loading and operating as expected.

I understand that this log often appears when additional drivers are installed, but for the following reasons, I’m unsure whether it’s safe to ignore this error:

  • The module name includes “Tegra.”
  • The same error does not occur in the sample environment provided by Nvidia.

Should I make some adjustments to the rootfs (or kernel)?

Apologies for the beginner’s question, but any advice would be appreciated.
Thank you for your time.

4

hello koichi.tanoiri,

please see-also Topic 301708, it means the signing key is different from your kernel building.

here’re couple of approaches to resovle this.

(1) you may configure CONFIG_MODULE_SIG as disabled to get rid of the message during modprobe/insmod.
or…
(2) you may try to specify your own sig_key using CONFIG_MODULE_SIG_KEY in kernel config, to rebuild the kernel and kernel modules, install the kernel image, dtbs and kernel modules to target. after that, please use your own sig_key to sign the *.ko built later.
please see-also developer guide for reference, [Kernel Module Signing].

2 Likes
5

Hello JerryChang,

Thank you for your prompt response. I will try modifying CONFIG_MODULE_SIG_KEY from its default setting.

However, I have an additional question regarding your response.

When building the kernel, if the key is regenerated by default, does that mean that the .ko modules are not rebuilt with this new signature? Or is it that this issue occurred because CONFIG_MODULE_SIG_ALL was not enabled during the kernel build, and if it had been enabled, there would be no problem even with the default key?

I would appreciate it if you could provide an answer. Thank you very much in advance.

Best regards.

6

hello koichi.tanoiri,

it has explained in Topic 301708, let me re-cap as below…

we have the CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" as the default setting.
the signing key is automatically generated in each kernel build, which means the signing key is different from each kernel building, thus, the kernel module compiled by user has different sig_key with the release one.

7

Thank you for your response.

I apologize; I understand your answer, but I might be misunderstanding the scope of key update and the authentication method in my kernel build due to my limited knowledge. I’ll outline my thoughts below—could you please review and let me know if there’s any misunderstanding?

First, when kernel build A is executed, both the kernel image with public key A and the .ko file signed with signature key A are created (=release build).
Then, when kernel build B is executed, both the kernel image with public key B and the .ko file signed with signature key B are created (=userbuild).
The current issue appears to be that one of the .ko files or kernel image has key A, while the other has key B.

However, I use both the .ko files and the kernel image that were built at the same time.
Therefore, I wondered if failing to set something during the kernel build might prevent key either the .ko files or kernel image from updating. (Here, I considered if the line from Developper Guide, “To enable automatic kernel module signing at build time, set CONFIG_MODULE_SIG_ALL,” might mean that unless CONFIG_MODULE_SIG_ALL is enabled, the .ko files won’t be signed.)

In the thoughts outlined above, where does it seem I might be mistaken?

Thank you for your time.

8

hello koichi.tanoiri,

FYI,
the CONFIG_MODULE_SIG_KEY=”certs/signing_key.pem” is the default setting for kernel module signature verification feature.
since you’re building your own modules, a new created *.ko has different keys already.

kernel has the ability to load unsigned modules, but it taints the kernel as a security precaution. this tainting serves as a warning (i.e. the message you’ve point-out) that the kernel may be running with unverified or unsafe code.

1 Like
9

Thank you for your response.

Based on your answer, is my misunderstanding summarized as follows?

when kernel build B is executed, both the kernel image with public key B and the .ko file signed with signature key B are created

In other words, when I build the kernel with default settings, the signatures of the newly created .ko files are updated, but the kernel image won’t necessarily accept these newly created signatures. Is this understanding correct? (Is my understanding that the kernel image itself has the function to verify signatures incorrect?)

Also, is my understanding correct that, unlike the default settings, changing CONFIG_MODULE_SIG_KEY from its default will also change the verifier information?

Thank you for your time.

10

hello koichi.tanoiri,

the signing key is automatically generated as long as you built the kernel.
please double check developer guide for details, [Kernel Module Signing].

11

Thank you for your response.

However, your response doesn’t seem to address my specific question. (our conversation may not be aligned due to my limited understanding.)

I am asking about points where the description in the Developer Guide, the answers in this forum, and the current situation don’t seem to align.

Current Situation:

The ko module signature and the verifier do not match.

Developer Guide:

By default, kernel modules are not signed at build time even if kernel module signature verification is enabled.

This states that .ko modules are not updated with default settings (although it seems they would be if CONFIG_MODULE_SIG_ALL is enabled).

If that’s the case, then this would make sense given the current situation.

Forum Response:

The CONFIG_MODULE_SIG_KEY=“certs/signing_key.pem” is the default setting for kernel module signature verification feature. Since you’re building your own modules, a new created *.ko has different keys already.

From this, it seems that the .ko modules are also updated by default (is CONFIG_MODULE_SIG_ALL enabled by default?).

If so, I don’t understand why there is a signature mismatch.

Regarding this, based on our previous conversation, I imagined that while the signature for .ko modules is updated, the verifier side does not automatically accept new signatures even if a kernel build is performed.
(Or does “newly created signature” in the default settings mean that it is in an “unsigned” state?)

I would like to confirm if this understanding is correct.
And I’d like to know how to update the verifier side.

Thank you for your time.

12

had you tried those two approaches as mentioned by comment #4 to resolve it?

13

I don’t believe the solutions proposed above align with the approach I’d like to take to resolve this. However, please feel free to correct me if I’m misunderstanding anything.

(1) you may configure CONFIG_MODULE_SIG as disabled to get rid of the message during modprobe/insmod.

My understanding here is that this option removes the error message but disables loading unsigned modules altogether.
I do not wish to stop loading modules.

(2) you may try to specify your own sig_key using CONFIG_MODULE_SIG_KEY in kernel config,…

My understanding here is that this option allows you to use a self-generated signature. But I do not necessarily need to use my own signature.
If there is some reason that key matching cannot work with the signature generated using the default configuration, I’d consider using this option. However, I don’t understand why it would work with a custom signature but not with the default signature.
Thus, I believe that, regardless of whether a default or custom signature is used, additional steps beyond just the build process may be necessary to achieve key matching, which is the basis for my question.

14

hello koichi.tanoiri,

kernel has the ability to load unsigned modules,
please configure CONFIG_MODULE_SIG as disabled to get rid of the message during modprobe/insmod.

15

kernel has the ability to load unsigned modules,

Yes, I understand that.

please configure CONFIG_MODULE_SIG as disabled to get rid of the message during modprobe/insmod.

However, I do not want to stop loading unsigned modules; rather, I would like the pcie_tegra194 .ko module to be correctly signed. I thought this would be possible because the pcie_tegra194 .ko module is created within the kernel build process. However, if my understanding is incorrect, please let me know.

16

hello koichi.tanoiri,

we’re not able to share the same sig_key to sign kernel modules. the signing key is automatically generated in each kernel build, which means the signing key is different from each kernel building, thus, the kernel module compiled by user has different sig_key with the release one.

17

Yes, I do not intend to ask you to share your private key.

What I’m curious about is simply this: “When building the kernel, isn’t a new private key and public key automatically generated, with the public key embedded in the kernel and the private key’s signature applied to the .ko modules (including pcie_tegra194)?”

Since a signature error actually appears, my understanding must be incorrect, and it seems that it doesn’t work this way. However, based on the explanations so far, I still don’t understand why it doesn’t work like this.

Thank you for your time.

18

hello koichi.tanoiri,

let me explain this way,
there’s a key used by native JP-6.1 release image. it’s using different key already with downloaded kernel sources to re-built kernel modules. it’s warning reported while you’re doing partial update.

in order to resolve that, you have to rebuild all the kernel and kernel modules, install the kernel image, dtbs and kernel modules to target for using the same key, otherwise it’ll report the same warning as well.

19

Thank you for your response.

In other words, if I use the kernel image, dtb, and modules from the same kernel build environment, this error log shouldn’t normally appear. This suggests that some parts of my kernel build artifacts might not be fully updated, resulting in a partial update. If that’s the case, I can understand the explanation.

I intended to replace everything—kernel image, dtb files, and modules—with those generated from the kernel build, but it’s possible that some parts were not updated. For now, I’ll check whether CONFIG_MODULE_SIG_ALL and other settings are functioning in the current build.

20

furthermore, please do follow developer guide, Kernel Customization to rebuild the kernel.

22

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.