Well I want to know for sure
.
Well, I could mention a bit. Especially after talking to VIt9696 about it.
This is something I've talked to many developers about before, also Clover developers, formerly TonyMac admin and developer PJALM and so on. And many of them have had some shared feelings about this, some have not. Throughout the history of macOS and bootloaders, opinions and thoughts have changed.
Here are some reasons why unsigned kexts should be injected via bootloader.
**-_Should and should_-** This is very opinionated. A reason I don’t really want to go on about it a lot.
Injecctions via bootloader secures early kext startup. This means there will be no problems with kexts such as Lilu and related kexts. Lilu being a kext that is becoming a main kext for many things, and will eventually be common standard for a lot, with its plugins etc. Hence the example of Lilu. This requires loading before root fs mount for policy installation.
If one installs to /Library/Extensions or /System/Library/Extensions, it requires rebuilding kext cache, whilst also ensuring permissions. This is more prone to error.
Damaged kexts in /Library/Extensions or /System/Library/Extensions are harder to replace. It requires running recovery, mounting boot fs, to analyse and finding the kexts, replacing them, setting permissions, running kextcache. With the bootloader, it is way easier, doing it via UEFI Shell, or other OS, such as Windows, BSD, Linux. As the MacOS drive is clean, and can be injected via another source, one could easily restore it that way as well.
If you Install to /Library/Extensions or /System/Library/Extensions, it requires you to disable System Integrity Protection (SIP). Regardless if you ignore security, this isn’t expected by Apple. Such systems will be less tested and more error prone.
On a real Mac, having secure boot (this will soon be with hackintosh as well using OpenCore), it isn’t possible to install third party early startup kexts, even if they are signed with authorised developer certificate. They can only load way after graphics startup. This doesn’t apply to Lilu and many other drivers. This is for example why a company such as NVIDIA can’t do much, with their drivers for MacOS.
There are of course downsides of kext injections.
Such as..
Injected kexts fall to property load dependencies and sometimes don’t load at all. This happens more with Clover. OpenCore lets XNU do it. Kext injections can break. Especially for Clover. As Clover relies on a method that is deprecated, and is no longer supported by Apple. However, it might still break for OpenCore. Though OpenCore is made with a different approach which is more reliable. Injected kexts lack some things, i.e. data information through API’s, allowing you to read files in kext directory. This will not work for injected kexts as their directories are not mounted. Though, many few kexts need it. In practice, you can rewrite every kext to avoid it.
So in this case, installing in /Library/Extensions and /System/Library/Extensions, as well ass injecting, could be good thing and a bad thing. Especially with Clover. Though the recovery stage could be a deal breaker. For newer methods, in this case OpenCore, one might want to rely on just injecting.
For me, the “just injecting” approach works well. With Clover and OpenCore. But to each their own.
"Just injecting" approach is also called the "vanilla method" by many people. I don't agree with that naming for such method. But calling something vanilla, you refer it to plain, original and clean. The only thing plain, original and clean from the third party injections is the drive, when you take it out. Having it in the hackintosh requires the third-party work around, regardless. Nothing "vanilla" with it, in my opinion. Though, it is "just injection" method. Perhaps saying "vanilla install" or "vanilla method" is easier and nicer.
