[NEEDED] Blocking kexts from Injection using config.plist to prevent macOS from not booting

Question

[NEEDED] Blocking kexts from Injection using config.plist to prevent macOS from not booting

LeeBinder opened this issue 4 years ago · 27 comments

With OC's way of injecting kexts, each kext incl. kexts in a kext's plugin folder is injected, creating two cases:

not every plugin kext is compatible with one's system
a plugin kext like VoodooInput if present in both, VoodooI2C and VoodooPS2, is detected as duplicate

both of which lead to macOS not booting.

The current work-around to always (manually or via script) remove problematic plugin kexts after an update is very awkward and needles to say not a solution.

Apparently, I'm not at all the only one who has been requesting this feature:

Question: How are you Clover devs going to tackle this?

A) The OC way with a list in which each present kext can/ needs to be enabled/ disabled?

B) A simple list with names of kexts to block?

C) A different approach in config.plist?

As always, thank you for your tireless and excellent work.

Work-around until this is solved: remove problematic kexts after update.zip

[EDIT] extending this request to also cover macOS system kexts in S/LE

Answer 1 · 2021-01-30T11:07:20.000Z

I didn't catch a reason to block a kext that you put into a Clover's folder. If you place a kext here then it is assumed that you need it else don't put a kext here.
If you want to block a kext in the preboot time then Clover already provide this possibility.

Answer 2 · 2021-01-30T11:20:45.000Z

Hi Sergey. It's not that much a kext itself but the kexts one does not obviously see because they are hidden inside kexts' plugin folder. Therefore OC provides that functionality:

If you want to block a kext in the preboot time then Clover already provide this possibility.

If with 'preboot' you indeed mean what I propose here (injection into the OS kext cache by Clover), then how does it work? I and others in the forum posts I linked to have been looking and searching for this feature, to no avail. It appears to be hidden deep away in some documentation. Can you please point to where it's explained? Thank you.

Answer 3 · 2021-01-30T11:32:12.000Z

SergeySlice commented 4 years ago

Answer 4 · 2021-01-30T12:13:36.000Z

I'm very much aware that it's possible to block kexts via Clover GUI/ Options etc., meant for emergency purposes if one has applied an incompatible kext and can't boot into macOS at all anymore. But certainly that's even more complicated and awkward than removing plugin kexts after an update and consequently not a solid solution, especially compared to what OC already offers, so the question from above remains: how are you Clover devs going to tackle this?

A) The OC way with a list in which each present kext can/ needs to be enabled/ disabled?

B) A simple list with names of kexts to block?

C) A different approach in config.plist?

Answer 5 · 2021-01-30T13:37:18.000Z

I see no reason to do this in config.plist.

Answer 6 · 2021-01-30T14:09:03.000Z

Fair enough. Maybe one of you other devs can see why the OC team introduced this feature in terms of usability, compatibility and user-friendliness, and why it will also make a lot of sense for Clover

@jief666 @Florin9doi @Sher1ocks @vectorsigma72 @asava @stevezhengshiqi @chris1111 @fishermans

Answer 7 · 2021-01-30T14:28:02.000Z

I would agree with @SergeySlice : if the kext is there, it has be loaded.
OC only provide one folder of kexts. That's why they need to be able to enable/disable in config.plist.
Clover handle many kexts folder depending of the version. The rule is : the folder content is the list to load.
If you want to disable a plugin, with OC you go in config.plist and modify, in Clover you go to the kext folder and delete (or move).
We definitely DON'T want to add also something in config as it is redundant : for example, if you want to add a kext, you need to modify the kext folder (add the kext with Finder) AND then add it to config.
For user-friendliness, I think it's good the way it is. Maybe we could add a duplicate detection and warning.
Think "different kext folder" instead of one folder for all versions with kext to block.

For a post you cited, one wants to have 2 differents config.plist. One that disable kext A and another that disable kext B. For that, it's now possible to have 2 different clover folder and use BootLoaderChooser to select at boot which one is wanted.

2 others ones wants to disable system kexts. @SergeySlice, is it even possible ?

Answer 8 · 2021-01-30T22:35:44.000Z

98ish% of all kexts load fine for all current macOS which is why the OC team decided to lump them all together to begin with.

macOS/ Mac OS X have always been scanning the plists inside kexts to decide which ones to include in the kernel cache. Even legacy Clover has been adhering to that principle in its own old way of injecting kexts, which was good in that regard. Then came OC with its brute kext injection, despite of known advantages to its technical functionality, forcing ALL kexts present in the Kexts folder path incl. any kexts in plugin folders to be injected, clearly contradicting Apple's guidelines.

Thus the main 98ish% reason for the section with the kext load list is to counteract that regression - NOT because of possible separate kext folders accdg. to macOS versions, if wanted.

if the kext is there, it has be loaded.

Imagine all Mac users would always have to browse through the Extension folder after each macOS update to get rid of all kexts incl. kexts in sub-locations to prevent their Mac from not booting on 1st start after an update. That exactly is the equivalent.

Sorry @jief666 @SergeySlice but honestly, only having adapted OCs brute kext injection but without the regulative section in config.plist is only half the battle, leaving Clover caught halfway between two stools, and the user fall through the cracks after updates of some kexts which include incompatible sub-kexts which simply MAY not be injected, leading to macOS not booting. VoodooPS2Controller.kext and AirportBrcmFixup.kext are the ones for my rig, but I am positive there are more.

Plain simple, that is a security hole and needs to be fixed urgently; esp. since a) it did not occur with legacy Clover and b) OC already offers one solution how to handle this securely and professionally.

My proposal for Clover: I do like Clover's # kext folders for macOS versions and agree that Clover style should be maintained. A simple kext block section where the mere names of kexts to be blocked from injection can be pasted would suffice.

Answer 9 · 2021-01-31T06:31:30.000Z

2 others ones wants to disable system kexts. @SergeySlice, is it even possible ?

Almost no. Clover has a possibility to block one kext from SLE but only temporary. Kernel anyway will load this kext later.
May be somehow Lilu can do this, I don't know.

@LeeBinder
I understand about kext update. Some user will update his kext, for example VoodooPS2Controller, by some automatic package and he will get unwanted plugin. You want to disable this plugin forever.
I think it is wrong wish. The package can erroneously place new kext in not wanted folder (remember 10,11,Other ...). You always should check the update result.

Answer 10 · 2021-01-31T07:43:48.000Z

2 others ones wants to disable system kexts

@jief666 They can use KextsToPatch and InfoPlistPatch to block system kexts. A common way to do this is to replace IOKit in info.plst with meaningless string, such as IOKis. This is an example of blocking AppleIntelLpssI2C.kext, credit VoodooI2C team:

<dict>
		<key>Comment</key>
		<string>Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar</string>
		<key>Name</key>
		<string>com.apple.driver.AppleIntelLpssI2CController</string>
		<key>Find</key>
		<data>SU9LaXQ=</data>
		<key>Replace</key>
		<data>SU9LaXM=</data>
		<key>InfoPlistPatch</key>
		<true/>
</dict>

It works perfectly before r5122, never tested on the newer Clover version.

Answer 11 · 2021-01-31T19:26:40.000Z

@stevezhengshiqi ah yes, kudos to your memory 👍

any chance this could work with kexts in Clover/kexts/..., too, as long as they have an entry IOKitPersonalities in their info.plist?

Also:

$ ioreg -l | grep acidanthera
    | |   |   "CFBundleIdentifier" = "as.acidanthera.voodoo.driver.PS2Controller"
    | |     |   "CFBundleIdentifier" = "as.acidanthera.voodoo.driver.PS2Controller"
    | |     |   |   "CFBundleIdentifier" = "as.acidanthera.voodoo.driver.PS2Keyboard"
      |     "CFBundleIdentifier" = "as.acidanthera.BrcmPatchRAM2"
            "CFBundleIdentifier" = "as.acidanthera.BrcmFirmwareStore"
$ 
$ ioreg -l | grep lvs1974
    | |         "CFBundleIdentifier" = "org.lvs1974.driver.CpuTscSync"
    | |         "RM,Version" = "org.lvs1974.driver.CpuTscSync 1.0.2"
    | |   |       |   "IOPersonalityPublisher" = "as.lvs1974.AirportBrcmNICInjector"
      |     "CFBundleIdentifier" = "as.lvs1974.AirportBrcmFixup"
      |     "CFBundleIdentifier" = "org.lvs1974.driver.CpuTscSync"
$

Answer 12 · 2021-01-31T20:11:01.000Z

As expected, no:

Restored original AirportBrcmFixup.kext containing (the for Big Sur problematic) AirportBrcm4360Injector.kext
to Clover config.plist, added

			<dict>
				<key>Comment</key>
				<string>Prevent AirPortBrcm4360_Injector from loading, Patch 1 - credit CoolStar</string>
				<key>Name</key>
				<string>as.lvs1974.AirportBrcm4360Injector</string>
				<key>Find</key>
				<data>SU9LaXQ=</data>
				<key>Replace</key>
				<data>SU9LaXM=</data>
				<key>InfoPlistPatch</key>
				<true/>
			</dict>
			<dict>
				<key>Comment</key>
				<string>Prevent AirPortBrcm4360_Injector from loading, Patch 2 - credit CoolStar</string>
				<key>Name</key>
				<string>com.apple.driver.AirPort.Brcm4360</string>
				<key>Find</key>
				<data>SU9LaXQ=</data>
				<key>Replace</key>
				<data>SU9LaXM=</data>
				<key>InfoPlistPatch</key>
				<true/>
			</dict>

-> Big Sur again does not boot as it does w/o the kext present.

Answer 13 · 2021-02-01T13:13:56.000Z

@SergeySlice I ran out of time y-day and am catching up with you now. You write,

I understand about kext update. Some user will update his kext, for example VoodooPS2Controller, by some automatic package and he will get unwanted plugin.

It does not matter if one or more kexts get updated via a update utility or if users update manually via extraction from a zip they downloaded, because the result remains the same: one or more kexts can obtain problematic plugin kexts which would interfere with macOS (esp. Bug Sur) boot.

You want to disable this plugin forever.

absolutely correct

I think it is wrong wish. The package can erroneously place new kext in not wanted folder (remember 10,11,Other ...). You always should check the update result.

That exactly is the argument for the cause I'm bringing across - here's why:
Regardless if after a kext(s) update, a problematic kext is in Other or some other folder, the user has to identify it no matter what. He either has to memorize that to remember to remove it again (= unsafe), or note it down somewhere. Why not type it into Clover right away into the section which could easily be there?

The path "issue" you're alluding to can be tackled in two possible ways:
a) simplest for the user and most professional: the code function behind this new section can simply use a kext name to decide injection or not of a kext, totally regardless of its folder location. That would require Clover have a duplicate kext
detection and warning as per @jief666, and it should then be activated by default (+ an extra key to deactivate it if wanted by some user for some reason).

b) the user needs to specify all possibly needed paths with Kexts as root, like (I'm taking forward-to-backward slash rewrite for granted here):

Other/VoodooPS2Controller.kext/Contents/PlugIns/VoodooInput.kext
11/VoodooPS2Controller.kext/Contents/PlugIns/VoodooInput.kext

In case new problematic plugin kexts are identified in the future, the user can simply add them there once and again be done with it for good! You see it's not even an issue.

Another argument is that Clover already has this functionality as you show in your screenshot

click to expand

so it doesn't even need to be coded from scratch but can now finally be brought from the "cellar" right into the main GUI to complete the new OC method of kext injection.

Here's where it would make most sense, I'd say:

<key>KernelAndKextPatches</key>
	<dict>
		<key>ExcludeKextsFromInjection</key>
		<array>
			<string>AirPortBrcm4360_Injector.kext</string>
			<string>VoodooPS2Trackpad.kext</string>
			<string>VoodooPS2Mouse.kext</string>
		</array>

Let me know if there is still anything left unclear and I'll gladly take it on :)

Answer 14 · 2021-02-01T14:36:02.000Z

I'm not really in favor of having 2 features that counteract each other. I mean : a kext folder which purpose is "every kext in there will be injected", and a feature in config.plist "every kext listed won't be injected".
If a plugin must not be used, maybe the problem is that this plugin should not be packaged with the kext...

Answer 15 · 2021-02-01T15:33:03.000Z

I'm not really in favor of having 2 features that counteract each other.

Harmonization/ balancing is how I look at it.

I mean : a kext folder which purpose is "every kext in there will be injected",

again: if L/E or even S/L/E function as guiding standard "role model", then only matching kexts accdg. to specific criteria are injected - it's even the majority which are ignored.

If a plugin must not be used, maybe the problem is that this plugin should not be packaged with the kext...

agreed! But tell that to acidanthera. We know what his reply will be... :(

Answer 16 · 2021-02-05T01:32:22.000Z

If a plugin must not be used, maybe the problem is that this plugin should not be packaged with the kext...

VoodooInput specifically is a little weird - it's a kext which both VoodooPS2 and VoodooI2C/VoodooRMI can use to send trackpad data to macOS. If a user isn't using VoodooI2C/VoodooRMI, then they would want VoodooInput from within VoodooPS2 to be used.

I'm not exactly sure why VoodooInput is distributed together with VoodooPS2/VoodooI2C rather than seperately - I suppose it's for convenience.

Edit: The two kexts are generally going to be the same version - you could check for duplicates in code and inject the latest version if there is a difference

Answer 17 · 2021-02-05T20:22:45.000Z

My ELAN1300 TP won't work w/o VoodooInput ever since they switched to it.

Latest version only injection: agreed.

AirPortBrcm4360_Injector.kext is a codeless (w/o binary) kext with merely an info.plist. @acidanthera : would Big Sur acknowledge a LSMaximumSystemVersion key with value 10.15 so BS ignores it so macOS 11.x would boot even with the kext present inside AirportBrcmFixup.kext? But why am I asking.. you made more than clear you don't give a d**n about anything Clover anymore

Answer 18 · 2021-02-06T17:07:38.000Z

In case new problematic plugin kexts are identified in the future, the user can simply add them there once and again be done with it for good!
The user can delete this plugin. No?

Answer 19 · 2021-02-06T17:09:59.000Z

Sure, with every update.

Answer 20 · 2021-02-06T17:10:42.000Z

But tell that to acidanthera. We know what his reply will be... :(
Oh, don't say that about Acidanthera...

Answer 21 · 2021-02-06T17:18:32.000Z

Jeff, he states that right on his github page - nothing Clover, only OC; and OC handles kext injection via in-/exclusion in config.plist. He closed my inquiry on his issues page right away, insisting it's to be accepted it be done the OC way, period. Couldn't get more straight forward.

Answer 22 · 2021-02-06T17:21:18.000Z

I'm so surprised. He's so flexible and open minded...

Answer 23 · 2021-02-06T17:24:59.000Z

If OC is not welcome here, this repository should get rid of it and insisit on the old kernel patcher right?

Answer 24 · 2021-02-06T17:27:59.000Z

@stevezhengshiqi it is very well welcomed.

Answer 25 · 2021-02-06T17:56:44.000Z

I'm so surprised. He's so flexible and open minded...

you're being sarcastic now, m8t, aren't you ?

Answer 26 · 2021-02-06T18:01:52.000Z

Me ? I don't even know what's the meaning of that word !

Answer 27 · 2024-01-14T20:15:33.000Z

Hi all.

Clover has a possibility to block one kext from SLE but only temporary. Kernel anyway will load this kext later.

is now obsolete because

Release 5157: Resolved issue with blocking a kext i.e. BlockSkywalk patch

Jief_Machak managed to block the Skywalk kext in SLE with that quirk w/o getting loaded by the kernel later, and even OS-specific (in this case just for Sonoma).

Continuing here rather than in the redundant issue which the commenter closed anyway, let's take stevezhengshiqi's instructions and the Skywalk kext as an example, because - when booting Sonoma with affected BCM hardware present + BlockSkywalk quirk NOT activated for testing - we see conveniently if the patch works or not -> immediate kernel panic if it does NOT get blocked! Again, Skywalk just as a perfect sample kext to find out how to block any kext in SLE for other scenarios.

How now would the section need to look like? As noted before, the following entry does not work:

<dict>
      <key>Name</key>
      <string>com.apple.iokit.IOSkywalkFamily</string>
      <key>Find</key>
      <data>SU9LaXQ=</data>
      <key>Replace</key>
      <data>SU9LaXM=</data>
      <key>InfoPlistPatch</key>
      <true/>
      <key>MatchOS</key>
      <string>14.x</string>
      <key>Comment</key>
      <string>Block macOS Sonoma built-in IOSkywalkFamily.kext</string>
      <key>Disabled</key>
      <false/>
</dict>

Jief, following your suggestion

I think matchos should 23. But again not sure.

I also tried 23 and all other alternatives I could think of (23.x, 23.x.xx,14, 14.x.xx), all of which don't work.

The code how to reliably block a kext in SLE is already known and present in Clover behind the BlockSkywalk quirk.

Again, I'm more than willing to continue beta testing on this :)