I'm finding that when I try loading the softRAID extension when I'm booted up on my M1 Mac using an external bootable device that has Reduce Security enabled, it will not load after Allowing it in System Preferences -> Security & Privacy and Restarting the Mac.
I even try loading with
kmutil load -p /Library/Extensions/softRAID.kext
but it spits out an error.
The Extension can be loaded only when I'm booted up on the M1 Mac's internal SSD running Big Sur.
Why is this ONLY an issue when booting up on a Reduced Security external bootable device ?
Thank you.
In addition to this issue, it's my understanding that Apple intends to abandon letting 3rd party loading Extensions, and have asked the 3rd party developers to start using Apple's provided APIs instead. See following Apple links discussing this...
https://support.apple.com/guide/security/kernel-extensions-sec8e454101b/1/web/1
https://support.apple.com/guide/security/startup-disk-security-policy-control-sec7d92dc49f/web
So the question arising from this is: when will softRAID abandon its need to load its kernel extension /Library/Extensions/softRAID.kext so that both internal and external bootable macOS Volume sets (OS+Data) do not need to load the kernel extensions ? This is especially important when boot from an external macOS volume set as I use this facility to test things without having to disturb my production internal macOS volume set that runs the official Apple macOS for the M1 Mac.
Thank you.
Did you know you need to reduce security on each boot volume? Perhaps you did not do that?
we are well aware of Apple's intentions, and we intend to be ready, however Apple is already a year late on "driver kit" to move the driver out. When they create a driver kit for drivers, we will of course work on that.
Thank you for your reply. Yes I had Reduced Security policy set on both the Internal and External boot volume sets. I had no problem loading the softRAID.kext for the Internal volume set, but couldn't manage it for the External volume set. I have the same issue with my PromiseSTEX.kext; I can log it for the Internal but not for the External. I assume this has to be a Apple bug at this time.
'Tis a shame Apple is so far behind on releasing their 'driver kit', and being a year late already. I guess we just have to be patient and wait.
When Apple does get their act together and provides the 'driver kit' and you re-work your driver to use this, how will you announce this to the general public.
Thank you.... I have been using softRAID since 2013 with my 2013 Mac Pro and have greatly admired its features.
Is this a clean install? another issue Big Sur has is with older extensions, it can block others from loading. that can also explain your Promise issue.
Attach a support file and i can check.
We will have a new version of SoftRAID with driver kit (when it works reliably). it will be a "significant" bump in the version, perhaps 6.5 or 7.0, depending on how far in the future it is.
@softraid-support Yes, both internal and external volume sets were 'clean & fresh' installs of Big Sur on my M1 mini, and yes I removed all kext files from /Library/Extensions except for the Promise and softRAID ones. Both the Promise and softRAID kexts were Universal and System Information -> Extensions displayed them as signed/notorized, so they should be good-to-go, right?
I will be looking forward to 6.5 and 7.0, and if the new driver kit works seamlessly this will be awesome not having to load the kexts and "Allow" and reboot after the cache has been rebuilt. It seems extending the kernel with these kexts today is a hot-and-miss process, and a tedious chore at best.
Thank you for the background and for the insights for the future softRAID versions 6.5 and 7.0.... and look forward to having them, and expect them to be available within a year hopefully.
One of our internal testers came up with an idea, to delete this file, which worked. I am not sure in your case, but might be worth a shot.
run this in terminal:
sudo rm -r /var/db/SystemPolicyConfiguration/KextPolicy

