Nvidia Web Driver updates for macOS High Sierra (UPDATE Nov 13, 2020)

MacDavePro · October 4, 2017

Oh, really? My Asus A43SJ laptop (take a look at my sig, google for detail specs) has only Single Nvidia graphics w/o IGPU. Can you give us some proofs to strenghten ur statement?

SavageAUS is using an i7-6700K as per his sig - this has an embedded IGPU.

UltraLaser is using an i7-7700K as per his sig - this has an embedded IGPU.

MICKHAEL is using an i7-6800K as per his sig - this does not have an IGPU.

This is why the procedure that worked for UltraLaser does not work for MICKHAEL despite their systems being otherwise very similar.

If you bothered to read the source for all the kexts and patches you tell people they should use you would understand this without me telling you.

I remember, on another thread u also said that "Lilu" kext with it's plugin opens the door for malware to exploit mac kernel (again, just said it w/o any data). Have u read that recently some malwares infected mac system as well and locked it's Firmware even on real mac device? Does a real one also use Lilu?

#EDIT: Ah, sorry @fantomas1. If my post looks offensive, or offTopic plz delete it. Thanks. BG.

Your comprehension needs work - I said that the combination of CsrActiveConfig == 0x67 + Lilu allows patching of arbitrary kernel functions and KEXTs by untrusted and unsigned code. It is trivial for a malicious coder to abuse this if you just go around installing stuff you don't understand. Which was my point - minimise the installation of things with privileged execution and make sure you understand what they do or get ready to have your bank accounts drained. That said it is also pretty simple to exfil your keychain with an unsigned binary right now on any Mac (or Hack) due to a serious security bug in High Sierra. Yes I do know about Mac malware - it is my job to know - but thank for trying to skool me anyway.

you tried other cable? DVI/HDMI?

I tried HDMI (I only have DP and HDMI on the 1080Ti). No joy. The issue seems to be that CoreDisplay doesn't see the discrete GPU as a MTL device. I think I'm going to need to hack up a DSDT/SSDTs to remap things to where OSX expects them for the fake board-id I am using (iMac17,1). I was already in the process of trying to figure out the board-id and serials for an iMac Pro to simplify my CPU setup but that wont help with the GPU issue anyway.

The thing that has me confused right now is that I had it working fine on the DPs using the 10.12.6 WebDriver. I think I was just lucky that that driver was broken just right for it to work. Another odd thing is that after installing the WebDriver I can't just nv_disable and boot to desktop. The WebDriver install messes something else up so I can only get back in via SSH to try new ideas and read the diagnostic crash reports. I might revert to a backup I took when it was working on the APPL nvidia driver and try again.

Badruzeus · October 4, 2017

it is my job to know - but thank for trying to skool me anyway.

U r welcum

MacDavePro · October 4, 2017

U r welcum

Oh - I suppose I should provide that proof you needed ...

https://github.com/vit9696/Lilu

... and here is an example usage to subvert a system call - you should recognise it if you are using NvidiaGraphicsFixup.kext (or not ) - do you understand what is happening here?

static const char *kextGraphicsDevicePolicy[] { "/System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/MacOS/AppleGraphicsDevicePolicy" };
static const char *kextGraphicsDevicePolicyId { "com.apple.driver.AppleGraphicsDevicePolicy" };

static const char *kextGeForce[] { "/System/Library/Extensions/GeForce.kext/Contents/MacOS/GeForce" };
static const char *kextGeForceId { "com.apple.GeForce" };

static const char *kextGeForceWeb[] { "/Library/Extensions/GeForceWeb.kext/Contents/MacOS/GeForceWeb" };
static const char *kextGeForceWebId { "com.nvidia.web.GeForceWeb" };


static KernelPatcher::KextInfo kextList[] {
    { kextGraphicsDevicePolicyId, kextGraphicsDevicePolicy, 1, {true,  false}, {}, KernelPatcher::KextInfo::Unloaded },
    { kextGeForceId,              kextGeForce,              1, {false, false}, {}, KernelPatcher::KextInfo::Unloaded },
    { kextGeForceWebId,           kextGeForceWeb,           1, {false, false}, {}, KernelPatcher::KextInfo::Unloaded },
};

static size_t kextListSize {3};

// Only used in apple-driven callbacks
static NGFX *callbackNGFX = nullptr;


bool NGFX::init() {
	if (getKernelVersion() > KernelVersion::Mavericks)
	{
		LiluAPI::Error error = lilu.onPatcherLoad(
		  [](void *user, KernelPatcher &patcher) {
			  callbackNGFX = static_cast<NGFX *>(user);
			  callbackNGFX->processKernel(patcher);
		  }, this);

		if (error != LiluAPI::Error::NoError) {
			SYSLOG("ngfx", "failed to register onPatcherLoad method %d", error);
			return false;
		}
	} else {
		progressState |= ProcessingState::KernelRouted;
	}
    
	LiluAPI::Error error = lilu.onKextLoad(kextList, kextListSize,
        [](void *user, KernelPatcher &patcher, size_t index, mach_vm_address_t address, size_t size) {
            callbackNGFX = static_cast<NGFX *>(user);
            callbackNGFX->processKext(patcher, index, address, size);
        }, this);
	
	if (error != LiluAPI::Error::NoError) {
		SYSLOG("ngfx", "failed to register onKextLoad method %d", error);
		return false;
	}
	
	return true;
}

void NGFX::deinit() {
}

void NGFX::processKernel(KernelPatcher &patcher) {
    if (!(progressState & ProcessingState::KernelRouted))
    {
        auto method_address = patcher.solveSymbol(KernelPatcher::KernelID, "_csfg_get_teamid");
        if (method_address) {
            DBGLOG("ngfx", "obtained _csfg_get_teamid");
            csfg_get_teamid = reinterpret_cast<t_csfg_get_teamid>(method_address);
            
            method_address = patcher.solveSymbol(KernelPatcher::KernelID, "_csfg_get_platform_binary");
            if (method_address ) {
                DBGLOG("ngfx", "obtained _csfg_get_platform_binary");
                patcher.clearError();
                org_csfg_get_platform_binary = reinterpret_cast<t_csfg_get_platform_binary>(patcher.routeFunction(method_address, reinterpret_cast<mach_vm_address_t>(csfg_get_platform_binary), true));
                if (patcher.getError() == KernelPatcher::Error::NoError) {
                    DBGLOG("ngfx", "routed _csfg_get_platform_binary");
                } else {
                    SYSLOG("ngfx", "failed to route _csfg_get_platform_binary");
                }
            } else {
                SYSLOG("ngfx", "failed to resolve _csfg_get_platform_binary");
            }
            
        } else {
            SYSLOG("ngfx", "failed to resolve _csfg_get_teamid");
        }
        
        progressState |= ProcessingState::KernelRouted;
    }
    
    // Ignore all the errors for other processors
    patcher.clearError();
}

void NGFX::processKext(KernelPatcher &patcher, size_t index, mach_vm_address_t address, size_t size) {
	if (progressState != ProcessingState::EverythingDone) {
		for (size_t i = 0; i < kextListSize; i++) {
			if (kextList[i].loadIndex == index) {
                if (!(progressState & ProcessingState::GraphicsDevicePolicyPatched) && !strcmp(kextList[i].id, kextGraphicsDevicePolicyId))
                {
                    DBGLOG("ngfx", "found %s", kextGraphicsDevicePolicyId);
                    const uint8_t find[]    = {0xBA, 0x05, 0x00, 0x00, 0x00};
                    const uint8_t replace[] = {0xBA, 0x00, 0x00, 0x00, 0x00};
                    KextPatch kext_patch {
                        {&kextList[i], find, replace, sizeof(find), 1},
						KernelVersion::MountainLion, KernelPatcher::KernelAny
					};
                    applyPatches(patcher, index, &kext_patch, 1);
                    progressState |= ProcessingState::GraphicsDevicePolicyPatched;
                }
                else if (!(progressState & ProcessingState::GeForceRouted) && !strcmp(kextList[i].id, kextGeForceId))
                {
                    DBGLOG("ngfx", "found %s", kextGeForceId);
                    auto method_address = patcher.solveSymbol(index, "__ZN13nvAccelerator18SetAccelPropertiesEv");
                    if (method_address) {
                        DBGLOG("ngfx", "obtained __ZN13nvAccelerator18SetAccelPropertiesEv");
                        patcher.clearError();
                        orgSetAccelProperties = reinterpret_cast<t_set_accel_properties>(patcher.routeFunction(method_address, reinterpret_cast<mach_vm_address_t>(SetAccelProperties), true));
                        if (patcher.getError() == KernelPatcher::Error::NoError) {
                            DBGLOG("ngfx", "routed __ZN13nvAccelerator18SetAccelPropertiesEv");
                        } else {
                            SYSLOG("ngfx", "failed to route __ZN13nvAccelerator18SetAccelPropertiesEv");
                        }
                    } else {
                        SYSLOG("ngfx", "failed to resolve __ZN13nvAccelerator18SetAccelPropertiesEv");
                    }
                    
                    progressState |= ProcessingState::GeForceRouted;
                }
                else if (!(progressState & ProcessingState::GeForceWebRouted) && !strcmp(kextList[i].id, kextGeForceWebId))
                {
                    DBGLOG("ngfx", "found %s", kextGeForceWebId);
                    auto method_address = patcher.solveSymbol(index, "__ZN19nvAcceleratorParent18SetAccelPropertiesEv");
                    if (method_address) {
                        DBGLOG("ngfx", "obtained __ZN19nvAcceleratorParent18SetAccelPropertiesEv");
                        patcher.clearError();
                        orgSetAccelProperties = reinterpret_cast<t_set_accel_properties>(patcher.routeFunction(method_address, reinterpret_cast<mach_vm_address_t>(SetAccelProperties), true));
                        if (patcher.getError() == KernelPatcher::Error::NoError) {
                            DBGLOG("ngfx", "routed __ZN19nvAcceleratorParent18SetAccelPropertiesEv");
                        } else {
                            SYSLOG("ngfx", "failed to route __ZN19nvAcceleratorParent18SetAccelPropertiesEv");
                        }
                    } else {
                        SYSLOG("ngfx", "failed to resolve __ZN19nvAcceleratorParent18SetAccelPropertiesEv");
                    }
                    
                    progressState |= ProcessingState::GeForceWebRouted;
                }
			}
		}
	}
    
	// Ignore all the errors for other processors
	patcher.clearError();
}

void NGFX::SetAccelProperties(IOService* that)
{
    DBGLOG("ngfx", "SetAccelProperties is called");
    
    if (callbackNGFX && callbackNGFX->orgSetAccelProperties)
    {
        callbackNGFX->orgSetAccelProperties(that);

        if (!that->getProperty("IOVARendererID"))
        {
			uint8_t rendererId[] {0x08, 0x00, 0x04, 0x01};
            that->setProperty("IOVARendererID", rendererId, sizeof(rendererId));
            DBGLOG("ngfx", "set IOVARendererID to 08 00 04 01");
        }
        
        if (!that->getProperty("IOVARendererSubID"))
        {
			uint8_t rendererSubId[] {0x03, 0x00, 0x00, 0x00};
            that->setProperty("IOVARendererSubID", rendererSubId, sizeof(rendererSubId));
            DBGLOG("ngfx", "set IOVARendererSubID to value 03 00 00 00");
        }
    }
}

int NGFX::csfg_get_platform_binary(void *fg)
{
    //DBGLOG("ngfx", "csfg_get_platform_binary is called"); // is called quite often
    
    if (callbackNGFX && callbackNGFX->org_csfg_get_platform_binary && callbackNGFX->csfg_get_teamid)
    {
        int result = callbackNGFX->org_csfg_get_platform_binary(fg);
        if (!result)
        {
            // Special case NVIDIA drivers
            const char *teamId = callbackNGFX->csfg_get_teamid(fg);
            if (teamId != nullptr && strcmp(teamId, kNvidiaTeamId) == 0)
            {
                DBGLOG("ngfx", "platform binary override for %s", kNvidiaTeamId);
                return 1;
            }
        }
        
        return result;
    }
    
    // Default to error
    return 0;
}

void NGFX::applyPatches(KernelPatcher &patcher, size_t index, const KextPatch *patches, size_t patchNum) {
    DBGLOG("ngfx", "applying patches for %zu kext", index);
    for (size_t p = 0; p < patchNum; p++) {
        auto &patch = patches[p];
        if (patch.patch.kext->loadIndex == index) {
            if (patcher.compatibleKernel(patch.minKernel, patch.maxKernel)) {
                DBGLOG("ngfx", "applying %zu patch for %zu kext", p, index);
                patcher.applyLookupPatch(&patch.patch);
                // Do not really care for the errors for now
                patcher.clearError();
            }
        }
    }
}

MICKHAEL · October 4, 2017

yes, i think remap things sounds good. i use mac pro 6.1 with DSDT fix

MacDavePro · October 4, 2017

Oh, really? My Asus A43SJ laptop (take a look at my sig, google for detail specs) has only Single Nvidia graphics w/o IGPU. Can you give us some proofs to strenghten ur statement?

Your GPU is a GF GT520M. Fermi is natively supported by the APPL nvidia driver. As a result you will not have the same problems a Pascal or Maxwell user has with discrete GPU.

I have no IGPU and method with kext it is working.

I have also patched apple policy (I don't have a vanilla kext to test if it is working also without patching it)

My comments to which Badruzeus reacted, and I replied, were about SavageAUS, UltraLaser and MICKHAEL trying to understand why his didn't work. I will have to skim back through the thread to review what config and kexts you used to figure out why yours works.

yes, i think remap things sounds good. i use mac pro 6.1 with DSDT fix

I can't use MacPro6,1 as I am on X299 with Skylake-X. Until I can correctly set frequency vectors for the 7900X for CPU power management I am using a Skylake system board-id.

MacDavePro · October 4, 2017

Not polemics in my assertion

I spent many time to solve using old method..

but an "unuseful" kext before for me solved black screen with signal problem

this one

NVWebDriverLibValFix.kext

I don't know why but this kext allowed me to have a perfect working system you can see in signature

That kext is not necessarily "not useful". It depends upon many factors - not the least of which is which versions of other kexts you have. Even just know the kext names doesn't tell the whole story because the contents change radically between versions. For example: lilu 1.1.7 plus NvidiaGraphicsFixup 1.1.2 might work on Sierra and fail on High Sierra while lilu 1.1.7 plus NGFX 1.1.3 works.

SavageAUS · October 4, 2017

@MacDavePro

My CPU does have an iGPU but it's disabled in bios so how is that even relevant to what I posted? I posted a success to confirm install methods etc.. nothing said about iGPU but I did say webdrivers so as per my sig I'm using a Nvidia gtx960 not iGPU.

MacDavePro · October 4, 2017

@MacDavePro

My CPU does have an iGPU but it's disabled in bios so how is that even relevant to what I posted? I posted a success to confirm install methods etc.. nothing said about iGPU but I did say webdrivers so as per my sig I'm using a Nvidia gtx960 not iGPU.

OSX knows from your CPU id that you have an IGPU. This can change how it maps your NV card as GFX0/GFX1 which changes the behaviour of CoreDisplay.framework. There are so many variables that what works for one person doesn't necessarily work for someone else unless they have exactly the same system. I wasn't saying there was anything invalid in you reporting success. Just that there are reasons it may work for you beyond what you think your kexts are adding.

MacDavePro · October 4, 2017

Thank you for your lecture...

;-)

her ewe are talking about high Sierra..so a minimal information on kext version to use should be a basic task to verify..or not?

I can't tell if that is sarcasm. If you wouldn't mind can you please list what kexts you have in EFI/CLOVER/kexts/Other (or 10.13 if that is how you have it) and what kext patches you have enabled (if any).

KGP-iMacPro · October 4, 2017

English divide us but I don't like your explanation ..it seems you are talking with an idiot..

no other patches only two kext you are listing (High Sierra release)

I fix policy with agpd fix app (how I say before because I am using 6.1MacPro smbios)

for me config.plist policy patch never worked..also the appropriate nvidiafix kext was not working to fix policy black screen with no signal

High Sierra nvidiaweb driver introduce for me a new black screen with signal..solved how I said before

I can confirm the success with this latter approach! See my post #280!

My System:

SMBIOS macPro6,1

i7-6950X (no igpu)

ASUS X99-A II

Gigabyte AORUS GTX 1080 Ti Extreme 11 GB

works flawless with 10.13 Web Driver and AGDPfix.app! Nothing else! No other fixes or patches for graphics!

However, I just received another user feed back for

SMBIOS macPro6,1

Asus X99 Deluxe II

i7-6900K (no igpu)

GTX 970

With this hardware configuration, the AGDPfix.app seems not to work... (I guess because of the GTX 970). The Asus X99 Deluxe II is basically identical with the Asus X99-A II and there should not be much difference either between using a i7-6950X or i7-6900K !

However, the user reports success with NVWebDriverLibValFix.kext, NvidiaGraphicsFixup.kext v1.1.3, and Lilu.kext v1.1.7 in /EFI/CLOVER/kexts/Other/ ! No other fixes or additional patches!

Cheers,

KGP

Badruzeus · October 4, 2017

Your GPU is a GF GT520M. Fermi is natively supported by the APPL nvidia driver. As a result you will not have the same problems a Pascal or Maxwell user has with discrete GPU.

Good point, Thanks . From a little bit long conversations above; it looks like we have a new dev here. Glad to know.

MacDavePro · October 4, 2017

I don't know yet. I am still reversing CoreDisplay to figure it out. I have the same issue.

Ok. I think I have found the reason for my WindowServer failing to start after installing the 10.13 WebDriver. And it has nothing to do with AGDP.

Note that NVWebDriverLibVal patches the system call to _csfg_get_platform_binary to trick macOS into thinking Nvidia's kexts are platform binaries, and that the motivation for this was to fix transparency issues with a few apps such as LittleSnitch that required this.

It was never a showstopper to boot to desktop.

Well that seems to have changed with AppleMobileFileIntegrity fixes that were likely added to address a well publicised dylib hijacking exploit combined with the new bundle packaging for Nvidia's WebDriver. Basically it would seem from the log that if the mapping process for the dylib load is a platform binary, then the loaded library must also be a platform binary or the library won't be loaded. In my case this is stopping the Nvidia MTLDriverWeb from loading which causes the WindowServer to crash because it has no MTL device to draw to.

This means that while decorating _csfg_get_platform_binary using NVWebDriverLibVal or similar (NvidiaGraphicsFixup trunk does the same thing) was previously optional it seems to be a requirement on High Sierra with Nvidia's WebDriver. This might explain why the former kext made the difference for @fabiosun.

What I don't understand is how the WebDriver works for real Macs. Could it be related to the WebDriver package installation error message that people keep saying to ignore? Does the WebDriver installer behave differently with SIP defaulted so as to use separate kexts instead of bundles?

I don't know but I will test with a _csfg_get_platform_binary hijacking patch to see if that fixes my black screen and let you know.

2017-10-04 19:37:21.693895+0000 0x7cc6     Error       0x0                  0      kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/System/Library/Extensions/GeForceMTLDriverWeb.bundle/Contents/MacOS/GeForceMTLDriverWeb' (Team ID: 6KR3T733EC, platform: no) for process 'WindowServer(1342)' (Team ID: none, platform: yes), reason: mapping process is a platform binary, but mapped file is not

2017-10-05 05:37:21.694216+1000 0x7cc6     Default     0x0                  1342   WindowServer: (CoreFoundation) Error loading /System/Library/Extensions/GeForceMTLDriverWeb.bundle/Contents/MacOS/GeForceMTLDriverWeb:  dlopen(/System/Library/Extensions/GeForceMTLDriverWeb.bundle/Contents/MacOS/GeForceMTLDriverWeb, 265): no suitable image found.  Did find:

2017-10-05 05:37:21.694610+1000 0x7cc6     Default     0x0                  1342   WindowServer: (CoreDisplay) [WARN] - No metal device for accelerator 0x357f

ok. and in my case, what should i try?

You should maybe read ^^^^ and give it a try yourself.

MacDavePro · October 4, 2017

Cheers,

KGP

dwhitla on tonymacx86

fixing your problem should be a pain if you are mixing two different kind of graphics chipset in your rig as I see

but I am pretty sure if you use only 1080ti NVWebDriverLibVal.kext should solve you black screen problem

I already have a generic kext that I wrote which allows you to mark any binary as a platform binary. I will just add the nvidia team id to my config - no big deal.

However, the user reports success with NVWebDriverLibValFix.kext, NvidiaGraphicsFixup.kext v1.1.3, and Lilu.kext v1.1.7 in /EFI/CLOVER/kexts/Other/ ! No other fixes or additional patches!

Just a tip - when NvidiaGraphicsFixup v1.2.1 is released (or you build it yourself from source on trunk) NVWebDriverLibValFix will be obsolete. The former includes the patches of the latter using Lilu 1.2.0.

I pasted the relevant source for NvidiaGraphicsFixup in #474 and have vetted it for safety.

MICKHAEL · October 4, 2017

ok, so interesting that with DVI no more black screen)... it's something messed with DIsplayPort

Asgorath · October 4, 2017

What I don't understand is how the WebDriver works for real Macs. Could it be related to the WebDriver package installation error message that people keep saying to ignore? Does the WebDriver installer behave differently with SIP defaulted so as to use separate kexts instead of bundles?

It seems like GateKeeper is involved on a real Mac when SIP is enabled:

https://forums.macrumors.com/threads/new-nvidia-web-driver-has-my-1080-tis-working-in-hs-10-13-sort-of.2073935/#post-25155249

The WindowServer now has Library Validation enabled in High Sierra, like iBooks and Little Snitch did back in Sierra:

~> codesign -d -v  /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
Executable=/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier=com.apple.WindowServer
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=391 flags=0x2000(library-validation) hashes=5+5 location=embedded
...

It sounds like when you hit the "Allow" button in the Security preferences, Apple does something to the NVIDIA binaries to allow them to load from then on. This process seems to not happen if you have SIP disabled (i.e. most Hackintoshes) which is why people need other methods of "fixing" Library Validation.

Badruzeus · October 4, 2017

It seems like GateKeeper is involved on a real Mac when SIP is enabled:

https://forums.macrumors.com/threads/new-nvidia-web-driver-has-my-1080-tis-working-in-hs-10-13-sort-of.2073935/#post-25155249

The WindowServer now has Library Validation enabled in High Sierra, like iBooks and Little Snitch did back in Sierra:
~> codesign -d -v  /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
Executable=/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier=com.apple.WindowServer
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=391 flags=0x2000(library-validation) hashes=5+5 location=embedded
...
It sounds like when you hit the "Allow" button in the Security preferences, Apple does something to the NVIDIA binaries to allow them to load from then on. This process seems to not happen if you have SIP disabled (i.e. most Hackintoshes) which is why people need other methods of "fixing" Library Validation.

Back to 27 September post; but on that day I just assumed there was "something" with SIP when installing Web Driver, at least if we're running it with SIP Disabled then show the installer logs..

chris1111 · October 4, 2017

This process seems to not happen if you have SIP disabled (i.e. most Hackintoshes) which is why people need other methods of "fixing" Library Validation.

Nvidia have a flag for Sip in the preinstall script packages

End

camillionario · October 4, 2017

strange:

Crs Active 0x0 = black screen
Crs Active 0x3 = ok graphics load
Tried to rebuild cache and same result

Asgorath · October 4, 2017

Nvidia have a flag for Sip in the preinstall script packages

End

Right, the installer is basically saying "Hey, you have SIP disabled which means the installation process might not work as intended. Are you sure you want to proceed?". That is, Gatekeeper won't flag the binaries as being allowed to load if SIP is disabled, which means the WindowServer won't load the non-Apple driver binaries, and thus you'll be stuck at a black screen. Solutions to this problem include enabling SIP and hitting Allow in Security Preferences when you first install the driver, or leaving SIP disabled and using a hack like the Library Validation fix kext.

Porkserver · October 5, 2017

I am also having some issues with my HS upgrade as well in regards to Nvidia stuff. Hoping folks can shed some light....

My upgrade and such went off without a hitch, I upgraded my file system to APFS. I use iMac 17,1 for my Machine ID as I have a skylake board (Is there something better to use these days?) In El Cap and Sierra all I needed was the web drivers and AGDPFix. I had black screens following this same method and I started to read up here and on Tonymac... After beating my face against the keyboard I kept getting black screen with the various methods. I reverted back to a vanilla environment and simplified my setup.... Lo and behold with a single monitor hooked to my card I made it to a fully accelerated desktop and web drivers were loaded properly.... After a lot of frustration I started ham fisting things just going trial and error. Long story short... Still just a single monitor will work in any of my 5 ports. 2 monitors gives black screens. This is using the AGDPFix and with using Lilu/NvidiaGraphicsFixup in Clover/Kexts/Other. Either of these methods seems to work for my card, the only common thing I found is without NVWebDriverLibValFix in my Clover/Kexts/Other I get no Blackscreen but do get framebuffer errors and no boot.

Anyone have an idea how to fixup the dual screen issue? My first guess is my DSDT may need further edits/patching or a possible setting in Clover I am not aware of...

MacDavePro · October 5, 2017

ok, so interesting that with DVI no more black screen)... it's something messed with DIsplayPort

Sounds like you might need to set your graphics card port configuration in Clover.

It seems like GateKeeper is involved on a real Mac when SIP is enabled:

https://forums.macrumors.com/threads/new-nvidia-web-driver-has-my-1080-tis-working-in-hs-10-13-sort-of.2073935/#post-25155249

The WindowServer now has Library Validation enabled in High Sierra, like iBooks and Little Snitch did back in Sierra:
~> codesign -d -v  /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
Executable=/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier=com.apple.WindowServer
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=391 flags=0x2000(library-validation) hashes=5+5 location=embedded
...
It sounds like when you hit the "Allow" button in the Security preferences, Apple does something to the NVIDIA binaries to allow them to load from then on. This process seems to not happen if you have SIP disabled (i.e. most Hackintoshes) which is why people need other methods of "fixing" Library Validation.

This is consistent with what I've been able to debug. Too bad that with my combination of hardware and every branch of OsxAptioFixDrv I can't boot with CsrActiveConfig == 0x0.

captain-j · October 5, 2017

I am also having some issues with my HS upgrade as well in regards to Nvidia stuff. Hoping folks can shed some light....

My upgrade and such went off without a hitch, I upgraded my file system to APFS. I use iMac 17,1 for my Machine ID as I have a skylake board (Is there something better to use these days?) In El Cap and Sierra all I needed was the web drivers and AGDPFix. I had black screens following this same method and I started to read up here and on Tonymac... After beating my face against the keyboard I kept getting black screen with the various methods. I reverted back to a vanilla environment and simplified my setup.... Lo and behold with a single monitor hooked to my card I made it to a fully accelerated desktop and web drivers were loaded properly.... After a lot of frustration I started ham fisting things just going trial and error. Long story short... Still just a single monitor will work in any of my 5 ports. 2 monitors gives black screens. This is using the AGDPFix and with using Lilu/NvidiaGraphicsFixup in Clover/Kexts/Other. Either of these methods seems to work for my card, the only common thing I found is without NVWebDriverLibValFix in my Clover/Kexts/Other I get no Blackscreen but do get framebuffer errors and no boot.

Anyone have an idea how to fixup the dual screen issue? My first guess is my DSDT may need further edits/patching or a possible setting in Clover I am not aware of...

Are the black screens you described WITH a signal (just showing black) or with NO signal (monitor eventually turns off)? In my case, I had a black screen with signal at boot due to my 10-bit color settings being retained from Sierra - it seems the web driver for HS doesn't support 10-bit (as yet). I had to screenshare in to my hack from my laptop and change the screen resolution in System Prefs, which reduced it to 8-bit color and brought signal back.

MICKHAEL · October 5, 2017

Sounds like you might need to set your graphics card port configuration in Clover.

This is consistent with what I've been able to debug. Too bad that with my combination of hardware and every branch of OsxAptioFixDrv I can't boot with CsrActiveConfig == 0x0.

Could you be more explicit about set graphics card port configuration in Clover. I want to try. thanks

Arslan2012 · October 5, 2017

weird situation for me. after updating to 10.13 from 10.12.6 my graphic cards second and third DisplayPort went black screen, but my first DisplayPort and HDMI both works fine.

my SIP is completely disabled, tried enabling it, everything is just the same.

PS: I have a EVGA GTX1060

MacDavePro · October 5, 2017

weird situation for me. after updating to 10.13 from 10.12.6 my graphic cards second and third DisplayPort went black screen, but my first DisplayPort and HDMI both works fine.

my SIP is completely disabled, tried enabling it, everything is just the same.

PS: I have a EVGA GTX1060

I don't know if it will help this case but perhaps take a look at this Clover config element.

Could you be more explicit about set graphics card port configuration in Clover. I want to try. thanks

Have a read of this - it explains it better than I could here.

Nvidia Web Driver updates for macOS High Sierra (UPDATE Nov 13, 2020)

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites