Leaderboard

Back in 2015 , when Apple introduced SIP protection in El Capitan, I quickly had a look at the SIP settings and associated CsrActiveConfig 8bit values in Enoch: nibble: 4 3 2 1 | 4 3 2 1 bits: - - - - | - - - - | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | \ Dev. Prot. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Prot. / \ Task Prot. Apple Int. Kernel Debug. Source: csr.h (in bsd/sys folder) of 10.11's published XNU source code at https://opensource.apple.com/ On the basis/assumption that Apple Internal & Device Configuration could be kept disabled by default (bit set to 0), CsrActiveConfig could be set to: 0000 0011 in binary, i.e. 0x03 (3 in decimal) to disable kext signing and filesystem protection 0110 0011 or 0110 1111 in binary, i.e. 0x63 or 0x6F (103 or 111 in decimal) to disable all protections that mattered If I booted Enoch in verbose mode with CsrActiveConfig=103 (i.e. 0x63), the displayed info showed: System Integrity Protection status: enabled (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state. At time of writing, in the days of Clover and Catalina, most people still use CsrActiveConfig 0x63 and that's fine. But there are also more flags to control SIP than there used to be in El Capitan: Sierra added a 9th flag for Any Recovery OS High Sierra added a 10th flag for Unapproved Kexts Mojave added an 11th flag for Executable Policy Override SIP is therefore arranged as follows: nibble: #3 | #2 | #1 nibble bits: 4 3 2 1 | 4 3 2 1 | 4 3 2 1 bits: 12 11 10 9 | 8 7 6 5 | 4 3 2 1 - - - - - - - - - - - - N/A | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | | | | | Policy Over. / | | | | | | | | | Kext App. / | | | | | | | | Recov. OS / | | | | | | \ Device Config. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Rest. / \ Task for PID Apple Int. Kernel Debug. where: Bit #1 = Allow untrusted kexts Bit #2 = Allow unrestricted FileSystem Bit #3 = Allow task for PID Bit #4 = Allow kernel debugger Bit #5 = Allow Apple internal Bit #6 = Allow unrestricted DTrace Bit #7 = Allow unrestricted NVRAM Bit #8 = Allow device configuration Bit #9 = Allow any recovery OS Bit #10 = Allow unapproved kexts Bit #11 = Allow executable policy override Bit #12 = N/A Source: csr.h (in bsd/sys folder) of Mojave 10.14's published XNU source code at https://opensource.apple.com/ Whilst the original CsrActiveConfig of 0x03 or 0x63 remains valid by far and large to most hackintoshers, some folks may also want to allow unapproved kexts on top of unsigned kexts. Keeping the same flags as for CsrActiveConfig 0x63 alongside, this would lead to a new value of 0010 0110 0011, i.e. 0x263 or 611 in decimal.

Up until this time last year, I had a Latitude E6440, a Haswell laptop fitted with HD4600 iGPU and AMD dGPU. The AMD dGPU was not supported and therefore disabled via DSDT/SSDT patching. There never was anything to be done on the iGPU front regarding performance per sé. Booting off the mSATA SSD was just about the same as with any other of my Hacks: ~20s from start to finish. I'm a little surprised to read that, on your Haswell desktop, enabling the HD4600 iGPU increases your boot time by almost 20s. I can't say ever heard of such an impact before. Did you try and analyse what happens at boot time through verbose mode when iGPU is on? Other than my Sandy Bridge Latitude E6220 and it's crappy HD3000, I find no particular performance issue on my other laptops running iGPU: whether it'd be my Ivy Bridge Latitude E6230 and its HD4000 iGPU or my Kaby Lake R Latitude 7490 and its UHD620 iGPU. Same applied to the Broadwell Latitude E7250 + HD5500 iGPU I had for a brief spell.

Hi @arsradu, yes we're aware of this recent issue and we're trying to solve this.

If you had been patching your own DSDT recently, you most likely encountered this common error dialogue when clicking on the 1st 2 errors, they'll take you to these set of codes To fix the errors, I created this patch which you can just apply with latest version of MacIASL This will fix all 3 errors listed above. Enjoy!