Explaining OS X El Capitan Security Changes - Workarounds and Current Information

[TomHsiung]

Kexts that are injected (from EFI/Clover/kexts) are never cached. Only kexts installed to /S/L/E or /L/E are placed in the cache (and even then, only the kexts that are needed by your system).

After restoring via Time Machine, the ethernet card would display in the Network Panel but not work (always in Red status). Only after I rebuilt the caches, the ethernet card would work (in Green status). And the driver of the ethernet card (AppleIntelE1000e.kext) was placed under /EFI/CLOVER/kexts. How to explain this phenomena?

Tom

 

[RehabMan]

After restoring via Time Machine, the ethernet card would display in the Network Panel but not work (always in Red status). Only after I rebuilt the caches, the ethernet card would work (in Green status). And the driver of the ethernet card (AppleIntelE1000e.kext) was placed under /EFI/CLOVER/kexts. How to explain this phenomena?

Tom

Ethernet kexts, such as AppleIntelE1000e.kext, have a dependency... IONetworkingFamily.kext.

So... it only works when IONetworkingFamily.kext is in the cache. Rebuilding cache puts IONetworkingFamily.kext into the cache, not AppleIntelE1000e.kext. Kexts that are injected are never placed in cache (unless they also exist in /S/L/E, of course).

You can also use ForceKextsToLoad to force IONetworkingFamily.kext to load. I use this so it works at installation/recovery, for example.

 

[TomHsiung]

Ethernet kexts, such as AppleIntelE1000e.kext, have a dependency... IONetworkingFamily.kext.

So... it only works when IONetworkingFamily.kext is in the cache. Rebuilding cache puts IONetworkingFamily.kext into the cache, not AppleIntelE1000e.kext. Kexts that are injected are never placed in cache (unless they also exist in /S/L/E, of course).

You can also use ForceKextsToLoad to force IONetworkingFamily.kext to load. I use this so it works at installation/recovery, for example.

Nice explanation, @RehabMan

Much appreciated.

Tom

 

[ultrazone]

Kexts that are injected (from EFI/Clover/kexts) are never cached. Only kexts installed to /S/L/E or /L/E are placed in the cache (and even then, only the kexts that are needed by your system).

Good to know, but I would like to ask you what happens with patched kexts (via Clover). For example, AppleHDA.kext lives in S/L/E, so it is cached. What would happen if I patch AppleHDA? Should I rebuild caches? When? How?

I'm on PB5 with SIP disabled completely. Thanks for all the info!

 

[RehabMan]

Good to know, but I would like to ask you what happens with patched kexts (via Clover). For example, AppleHDA.kext lives in S/L/E, so it is cached. What would happen if I patch AppleHDA? Should I rebuild caches? When? How?

I'm on PB5 with SIP disabled completely. Thanks for all the info!

Patches via config.plist patch the kext that is in cache when Clover loads the cache from disk.

 

[Wb5qwn]

This was just posted on ******, I wonder if true and what the hex values are:

That half-assed configuration panel used in previous El Capitan recovery systems is no more.
Yeah, I was also nervous for a moment when I found this out. Nothing to worry about though: Those looking to disable System Integrity Protection may do so via the csrutil command line utility in recovery mode:
csrutil disable
To compliment its new role, csrutil now offers a higher level of customization; Individual aspects to System Integrity Protection may now be enabled or disabled individually:
csrutil enable \
--without kext \
--without fs \
--without debug \
--without dtrace \
--without nvram
If you would like to prevent the modification of your boot parameters, for example, but without the filesystem lockdown getting in your way, this would now possible like so:
csrutil enable --without fs
Anyway, spread the word, and enjoy!

 

[Wb5qwn]

I am on PB5 also and setting to enable will not allow me to boot. The progress bar goes all the way over and stays there for evernity. However setting to x3 goes to login in about 15 seconds from starting it. However bluetooth takes about 30 minutes to initialize.

 

[PencilNotPen]

Thanks for the summary. Having read your sources too, I cannot find an explanation of the booterconfig field for Clover. It is always included, and always 0x28. What does this flag control separate from csrconfig, and what other values are possible apart from 0x28?

Thanks

 

[VioletDragon]

@PencilNotPen set BooterConfig to 0x28 and CsrActiveConfig to 0x3 in Rt Variables in Clover Configurator.

 

[086_naseer]

Can I update current Yosemite to El Capitan.