I have version 26.1.1 and macos Sequoia and Tahoe as VMs running on it. I am trying to install NTFS read/write app from a vendor and it requires allowing 3rd part kext file. I am planning to switch the app and wanted to install the candidate on VM to see how easy to use before making a decision. I couldn't pass kext permission. Then I tried to install the one I currently use on my actula mac and it was same the result. I also tried both apps on both Sequoia and Tahoe VMs but it was always same failure. Startup security of both VMs is reduced as I do it on physical machine. When I allow the newly installed extension it restarts as usual but then it throws an error about loading extensions as well as extension list update notification. Both leads to same extension setting and it makes me review the extension with enabled option (grayed out cannot be disabled) then after closing as approval it asks me to restart. after restart same error and warning appears and it continues as a loop. Is there somehing I am missing or there is an issue with kext loading on VMs?
I assume you're running on an Apple Silicon Mac, trying to install a third party kext into a macOS guest VM. Parallels macOS guest VMs basically just use Apple's Virtualization Framework. The problem you're seeing is a design flaw in it. It's already been [reported for UTM macOS VMs](https://github.com/steven-michaud/HookCase/issues/19). I have a [workaround](https://gist.github.com/steven-michaud/fda019a4ae2df3a9295409053a53a65c), but it's very complex, and probably only suitable for someone who's actually developing a kext for use on Apple Silicon Macs, or trying to port one to Apple Silicon.
I should note that Apple has decided not to fix this design flaw: https://gist.github.com/steven-mich...malink_comment_id=5763622#gistcomment-5763622. But if enough people complain to them, it's possible (though not likely) that they'll change their minds.
I see. I am not doing anything custom though. It is an app from an identified developer. I know Parallels on silicon uses native features. If it is up to Apple they are notorious to ignore reasonable requests since the first version of iOS and OS X, They do it if they wish not if it is needed or useful.
Actually, even Apple's own kexts can be effected by this design flaw. Technically, the problem is that only kexts in a VM's "kernel cache" can be loaded into that VM. The "kernel cache" is a file that comes with the macOS installer (for VMs its IPSW file), and never changes (except possibly during a macOS upgrade). Third party kexts, and Apple kexts not in the "kernel cache", end up in an "auxiliary cache", which is dynamically created and managed. But the "auxiliary cache" (AuxKC) doesn't work properly in Virtualization framework VMs. So in this case, it doesn't matter whether or not a third party kext has been signed by Apple. You can load your NTFS kext "on bare metal" (into a macOS partition that's not a virtual machine). But, as you're aware, a buggy file system kext might destroy your machine's file system :-( Apple needn't worry about it's own kexts being effected by this design flaw. If a kext is important enough, they can just move it into the "kernel cache".
