"Bad code signature" happens during kext installation.

Hi there,

While developing my first kernel extension for a learning purpose, I'm facing the issue above, "Bad code signature".

The actual steps to reproduce are as follows: \

  1. Initialize my Xcode project using the template "Generic Kernel Extension".
  2. Implement a fundamental extension that displays "Hello World!" using printf();.
  3. Build and sign it as "Sign to run locally".
  4. Put the "HelloWorld.kext" bundle into the /Library/Extensions/.
  5. Change the owner of the bundle file to "root:wheel".
  6. Load the extension using as follows.
$ cd /Library/Extentions
$ sudo kextload /Library/Extensions/HelloWorld.kext
Password:
Executing: /usr/bin/kmutil load -p /Library/Extensions/HelloWorld.kext
Error Domain=KMErrorDomain Code=29 "Authenticating extension failed: Kext com.martymarron.HelloWorld v.1.0.0 in executable kext bundle com.martymarron.HelloWorld at /Library/Extensions/HelloWorld.kext:

Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext com.martymarron.HelloWorld v1.0.0 in executable kext bundle com.martymarron.HelloWorld at /Library/Extensions/HelloWorld.kext:

Authenticating extension failed: Bad code signature}

I guessed that the bundle needs to be signed anyway. Hence I signed it for "development", but it resulted in the same. Some article says that my developer account should be enabled for "KEXT development" on https://developer.apple.com/resources/developer-id/, but this link does not work now. Referred article: https://developer.apple.com/forums/thread/30703

Then, I found the article below says "the kernel doesn't load a kext if an equivalent System Extention solution exists". https://developer.apple.com/documentation/kernel/implementing_drivers_system_extensions_and_kexts

Does this mean the kernel extension development on my environment is no longer supported? Or is there still the way to try the kernel extension development on my environment? If no, I'll give up trying it and will try "system extension development" instead.

Thanks for your kind help!

My development environment:

  • OS ver: Monterey(12.5)
  • CPU Arch: Intel Core i7
  • Xcode ver: Version 13.4.1 (13F100)
Up vote post of MasashiKurita Down vote post of MasashiKurita
1.8k views
Posted by
MasashiKurita
Reply
Add a Comment

Accepted Reply

this link does not work now

Yeah, that’s annoying (more annoying is that I can’t fix the link)-: Anyway, the latest version of that page is here.

Does this mean the kernel extension development on my environment is no longer supported?

macOS will still load some third-party KEXTs. For this to work in production:

  • The relevant subsystem must still use KEXTs. For example:

    • The network subsystem no longer loads network kernel extensions (NKEs) because those have been disabled in favour of Network Extension providers.

    • The VFS subsystem still supports KEXTs, although at some point those are likely to go away in terms of file providers.

    • On the I/O Kit front, much of that support has migrated to DriverKit.

  • The KEXT must be signed with a KEXT-enabled Developer ID. For more on that, see KEXT Code Signing Problems.

  • The KEXT must be notarised.

During development you can avoid the need for a KEXT-enabled Developer ID by disabling SIP.

What are you trying to do with a KEXT? Our general advice has always been that you avoid writing code for the kernel if at all possible. Indeed, the first section of the Kernel Programming Guide is entitlement Keep Out! These days you have a wealth of alternatives and it’s best to explore those first.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved

  • Thank you so much for your quick response! Though I haven't tried the suggested solutions yet, let me answer your below question first. Responded as a new comment below due to character limits ;)

    —
    MasashiKurita

  • Sorry for my belated response!

    I successfully loaded my first kernel extension by disabling SIP. As I mentioned in the following comment, I won't plan to distribute this, hence this is enough for me for now.

    Thank you again for your detailed, and kind support :)

    —
    MasashiKurita
Add a Comment

Replies

this link does not work now

Yeah, that’s annoying (more annoying is that I can’t fix the link)-: Anyway, the latest version of that page is here.

Does this mean the kernel extension development on my environment is no longer supported?

macOS will still load some third-party KEXTs. For this to work in production:

  • The relevant subsystem must still use KEXTs. For example:

    • The network subsystem no longer loads network kernel extensions (NKEs) because those have been disabled in favour of Network Extension providers.

    • The VFS subsystem still supports KEXTs, although at some point those are likely to go away in terms of file providers.

    • On the I/O Kit front, much of that support has migrated to DriverKit.

  • The KEXT must be signed with a KEXT-enabled Developer ID. For more on that, see KEXT Code Signing Problems.

  • The KEXT must be notarised.

During development you can avoid the need for a KEXT-enabled Developer ID by disabling SIP.

What are you trying to do with a KEXT? Our general advice has always been that you avoid writing code for the kernel if at all possible. Indeed, the first section of the Kernel Programming Guide is entitlement Keep Out! These days you have a wealth of alternatives and it’s best to explore those first.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved

  • Thank you so much for your quick response! Though I haven't tried the suggested solutions yet, let me answer your below question first. Responded as a new comment below due to character limits ;)

    —
    MasashiKurita

  • Sorry for my belated response!

    I successfully loaded my first kernel extension by disabling SIP. As I mentioned in the following comment, I won't plan to distribute this, hence this is enough for me for now.

    Thank you again for your detailed, and kind support :)

    —
    MasashiKurita
Add a Comment

Hi @eskimo,

Thank you so much for your quick response!

Though I haven't tried the suggested solutions yet, let me answer your below question first.

What are you trying to do with a KEXT? Our general advice has always been that you avoid writing code for the kernel if at all possible. Indeed, the first section of the Kernel Programming Guide is entitlement Keep Out! These days you have a wealth of alternatives and it’s best to explore those first.

I'm now conducting the feasibility study that implements the "macOS containers" such as the Linux containers below. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/overview_of_containers_in_red_hat_systems/introduction_to_linux_containers

To share the context a bit more, I'm working on improving the iOS/macOS app development CI(=Continuous Integration) experience. Due to circumstances, Xcode cloud, on-premise Xcode server, ...etc are not suitable for me. * Actually, for "my development team". Further, hypervisor framework and virtualization framework are not suitable from the performance perspective.

Thus I'm exploring the possibility of macOS containerization. To design containerization architecture, it's necessary to know how to handle low-level resources like CPU, I/O, network I/F, ...etc via low-level APIs like the macOS kernel.

Learning how to build kernel extension is just the first step of this loooong journey of study. Of course, I understand well that these sorts of low-level implementations are black-boxed, and shouldn't be touched lightly.

Nevertheless, I'm curious to seek the way. I also welcome your, and the anyone's thoughts on this topic ;)

Posted by
MasashiKurita
Up vote reply of MasashiKurita Down vote reply of MasashiKurita
Add a Comment

I'm now conducting the feasibility study that implements the "macOS containers"

I don’t think there’s any supported path to that goal. To start, there’s no KPI (kernel programming interface) to support this sort of thing directly. In the absence of that, you’d have to do some serious kernel hackery. Even prior to the KEXT-ectomy process we started in macOS 10.15, the macOS KEXT architecture would’ve been too restrictive for your needs

Now, if you replace macOS’s kernel from one built from the Darwin source then anything is possible, but that’s not a supported path. And by supported I mean supported by DTS. And the reason we don’t support that is that our goal is to help developers build products with the prospect of long-term binary compatibility, and this approach is not that. I’d hate for you to spend a bunch of time working on this only to find that it irrecoverably breaks sometime in the future.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • First, thank you again for your quick response!

    According to your clarification, I understand well that my approach must come to a dead end. I need to look for another way to achieve it. Anyway, I'll keep learning KPIs for my curiosity within the scope that Apple officially supports. I don't want to break anything, just want to contribute growing software ecosystem surrounding Apple software.

    Again, I really appreciate you sharing your valuable and considerable thoughts on this topic :)

    —
    MasashiKurita
Add a Comment

Hi MasashiKurita and Quinn,

I have the same basic goal and the same basic issue -- I want to install a kext on my own machine for research purposes, but I cannot get it to install on macOS 12.5.1. (The kext installs and runs perfectly on 10.15.7.). Yes, I have disabled SIP, yes I have signed it as "Sign to run locally," yes I have changed the ownership "root:wheel" and moved the bundle to /Library/Extensions, yes I have granted permission in the "Security & Privacy" panel, and yes I have restarted. "sudo kmutil print-diagnostics [kext file]" tells me that the dependencies are OK and does not complain about ownership. But it also tells me that the kext has a "Bad Code Signature." The "System Information" utility similarly reports a "Kext signature validation error code -67050."

What is the trick? Apple Developer told me that I could install a kext on my own machine without a "KEXT-enabled Developer ID." But how -- what is the magic combination?

MasashiKurita, you wrote that you "successfully loaded [your] first kernel extension" on macOS 12.5. How did you do it?

Thanks for your help.

Eric Grant

Posted by
applepi
Up vote reply of applepi Down vote reply of applepi

  • Hello, I am also experiencing the same issue. Do I need to use the "Apple Develop Program" and use the correct certifications to use correctly on MacOS M1/M2? Does it have to be notarized?

    —
    XuMoxiao
Add a Comment