Contribute
Register

SIP (CsrActiveConfig 0x67 vs 0x00)

Status
Not open for further replies.
Joined
Sep 10, 2016
Messages
46
Motherboard
Intel NUC7
CPU
i3
Graphics
Intel HD 620 Integrated Graphics
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
So to install and update Nvidia Web drivers in High Sierra we have to set CsrActiveConfig to 0x00, which (as I understand it) enables SIP. Then we are supposed to set it back to 0x67, disabling SIP.

Why keep SIP disabled if we can run with it enabled? What advantage is there?
 
So to install and update Nvidia Web drivers in High Sierra we have to set CsrActiveConfig to 0x00, which (as I understand it) enables SIP. Then we are supposed to set it back to 0x67, disabling SIP.

Why keep SIP disabled if we can run with it enabled? What advantage is there?
You can leave it disabled and use the attached script to install the drivers on a fresh install or otherwise. For OS upgrades and updates there is no need to change your CSR active config when the drivers were already installed and working previously.

More generally if you have no unsigned kexts installed to /Library/Extensions or /System/Library/Extensions and neither you nor the software you use requires unrestricted filesystem access - there is nothing to stop you from booting with CSR 0x0. If you encounter problems you can change to a more permissive value. 0x67 is an arbitrary value apparently used in El Capitan and made famous by Clover's config.plist. Not sure if Macs use it for anything. Many hacks would want to run with 0x3 at least due to unsigned kexts installed where they go into the kext cache.
 

Attachments

  • altnvweb-121.sh.zip
    1.8 KB · Views: 434
Interesting. I think my only non-Apple kexts are in EFI/CLOVER/kexts/Other. Just the usual for ethernet, the Nvidia fix, etc. Nothing special.

So it sounds like I might be OK with SIP on (0x00). Hmmm. I may have to play with this.
 
Interesting. I think my only non-Apple kexts are in EFI/CLOVER/kexts/Other. Just the usual for ethernet, the Nvidia fix, etc. Nothing special.

So it sounds like I might be OK with SIP on (0x00). Hmmm. I may have to play with this.
Note that when installing/updating e.g. booting the recovery/installer environment things may not work properly with that setting.
 
A ha! And that's a good reason to stay 0x67. Thanks!
 
Note that when installing/updating e.g. booting the recovery/installer environment things may not work properly with that setting.
So you saying if you run MacOS with 0x00. You may have problems installing some software, and upgrading the OS, once new updates to HS come out?
Interesting, I have ran El Capitan, and Sierra at 0x3 successfully. Only in HS have I changed SIP to 0x00 to install Nvidia drivers (which also don't appear to work without helper kext files). This whole thing is strange to me, maybe we are getting buggy drivers from Nvidia, maybe this is a HS thing.
I saw somewhere on this site, someone post that newer versions of the driver don't require you to change SIP to 0x00, but that's a lie.
 
So you saying if you run MacOS with 0x00. You may have problems installing some software, and upgrading the OS, once new updates to HS come out?
Interesting, I have ran El Capitan, and Sierra at 0x3 successfully. Only in HS have I changed SIP to 0x00 to install Nvidia drivers (which also don't appear to work without helper kext files). This whole thing is strange to me, maybe we are getting buggy drivers from Nvidia, maybe this is a HS thing.
I saw somewhere on this site, someone post that newer versions of the driver don't require you to change SIP to 0x00, but that's a lie.

SIP should be disabled at all times. 0x67.
If not disabled there will be problems with Kext Injection, Booting problems.
 
Not sure if Macs use it for anything.

Developer use this as they develop new kernel extensions and test them it is a requirement. We know about disabling SIP because Apple let us know about it. See here. Apple makes obtaining Developer ID kext signing certificates difficult to obtain. Which are needed for properly signed kexts. Mainly because they don't want a lot of 3rd party kernel extensions. They feel as if they provide all the needed kexts for their machines. For the most part they do. There are only a handful of 3rd party kexts included in the macOS software package.

SIP should be disabled at all times. 0x67.
If not disabled there will be problems with Kext Injection, Booting problems.

SIP only needs to be disabled during kextcache rebuilding. This is the only time that with it enabled it would cause you problems. Now this happens during updates and when installer packages are run like Nvidia web drivers and any other time it might be run. Personally in my opinion one should just leave it disabled. However you if you would like to test your system to see for yourself that it can be fully enabled with unsigned kexts and everything work properly do the following. Leave it disabled in your config.plist with 0x28 and 0x67 and reboot the machine and at the clover boot menu select options, system parameters, system integrity protection and uncheck all the tick boxes then return and select boot_args and uncheck all tick boxes then proceed to boot the system and all unsigned kext will load as long as SIP was disabled during the last kextcache rebuild.
 
Developer use this as they develop new kernel extensions and test them it is a requirement
I meant a hard-coded csr active config 0x67. Mac users presumably use csrutil or spctl from recovery to allow for kext development, while the CSR flags are set automatically for other situations as needed. On hacks the value is re-created by Clover each boot based on the following and the value in config.plist

From csr.h in XNU

Code:
/* Rootless configuration flags */
#define CSR_ALLOW_UNTRUSTED_KEXTS        (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS        (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID            (1 << 2)
#define CSR_ALLOW_KERNEL_DEBUGGER        (1 << 3)
#define CSR_ALLOW_APPLE_INTERNAL        (1 << 4)
#define CSR_ALLOW_DESTRUCTIVE_DTRACE    (1 << 5) /* name deprecated */
#define CSR_ALLOW_UNRESTRICTED_DTRACE    (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM    (1 << 6)
#define CSR_ALLOW_DEVICE_CONFIGURATION    (1 << 7)
#define CSR_ALLOW_ANY_RECOVERY_OS    (1 << 8)
#define CSR_ALLOW_UNAPPROVED_KEXTS    (1 << 9)

In this sense 0x67 is totally arbitrary/magical
 
Last edited:
Status
Not open for further replies.
Back
Top