Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

 

 

You are conflating injecting and loading, injecting is done by the bootloader, loading is done by the kernel. They are actually mutually exclusive but clover patches it so they are not. Injection into the kernel happens through the data hub and the device tree memory map, it is not validated because SIP does not apply to booter extensions. When it's loaded that's when it's validated by the kernel (or when the cache is created), this is where SIP would prevent an unsigned kext from loading. CsrActive=0 is SIP fully enabled, meaning you have all security protections.

 

I should have realized, more my fault... I knew.

Thanks for the explanation.

 

Thanks for the link.

  • Like 1
Link to comment
Share on other sites

 

It's actually not that clear... Even I'm not sure exactly what that's doing. Where is it patching SIP? For the booter extensions or for loading?

 

EDIT: If for loading then why? Shouldn't just set CsrActive=0x1? If for booter extensions that makes sense.

 

EDIT2: Damn there need to be some more comments and they should be more descriptive when something is not completely obvious.

  • Like 1
Link to comment
Share on other sites

It's actually not that clear... Even I'm not sure exactly what that's doing. Where is it patching SIP? For the booter extensions or for loading?

 

EDIT: If for loading then why? Shouldn't just set CsrActive=0x1? If for booter extensions that makes sense.

Well, we've started patching com.apple.rootless.kext-management since 10.11 as it should be.

Yes. KBE*SIP is the patch for loading. Csr=0x1 will have something to do with kextd/kextcache/etc that deal with kexts, yet IOUserClient::copyClientEntitlement check is bypassed by KBE*SIP.

 

 

 

EDIT2: Damn there need to be some more comments and they should be more descriptive when something is not completely obvious.

Of course you could check the disasm by yourself and add more info for further convenience :)

Link to comment
Share on other sites

Well, we've started patching com.apple.rootless.kext-management since 10.11 as it should be.

Yes. KBE*SIP is the patch for loading. Csr=0x1 will have something to do with kextd/kextcache/etc that deal with kexts, yet IOUserClient::copyClientEntitlement check is bypassed by KBE*SIP.

 

Of course you could check the disasm by yourself and add more info for further convenience :)

 

I mean something more like that, like what is actually happening. That's a much more useful comment than what's in the code. I certainly don't want to check the disassembly to figure out what's going on. It is 100% the responsibility of the writer of the code to comment well enough that others can understand without having to completely redo the entire process. There's a reason there's so much dead and unnecessary code..... Because some of it we don't know if it's safe to remove and some of it just lingers because it works but no one wants to change it for fear that it won't work.

 

EDIT: Seriously, I would fire anyone who wrote code that wasn't sufficiently commented before someone who just wasn't as good at coding but commented well.

  • Like 2
Link to comment
Share on other sites

I mean something more like that, like what is actually happening. That's a much more useful comment than what's in the code. I certainly don't want to check the disassembly to figure out what's going on. It is 100% the responsibility of the writer of the code to comment well enough that others can understand without having to completely redo the entire process. There's a reason there's so much dead and unnecessary code..... Because some of it we don't know if it's safe to remove and some of it just lingers because it works but no one wants to change it for fear that it won't work.

Actually I'm also not the original author of these patches, and sure it took me some time to figure out how they were done.

I could share some docs written by myself, on how to find these patches out.

 

(Sorry for my bad English though)

kernel_patch_EN.txt

 

(And also in zh-TW, which is the original one)

kernel_patch_zh_TW.txt

  • Like 2
Link to comment
Share on other sites

Actually I'm also not the original author of these patches, and sure it took me some time to figure out how they were done.

I could share some docs written by myself, on how to find these patches out.

 

That wasn't directed at you, it was just a general statement. The code base for clover is becoming massive, can't remember every tiny detail of everything done years ago. It needs comments, that's why they exist. And that is slightly more detail than needed, lol. But a summarized version of that without all the actual data (because we are looking for more abstract stuff) would be the correct way to comment. Something like "patching this method for this reason at this place with any relevant notes," like you said above.

 

EDIT: Also it's very important to write when you are unsure of some code or that it might have a side effect. Oh god is that important.

  • Like 1
Link to comment
Share on other sites

Ah.... Ummm.... Why you bought a board with an Insyde firmware? Then how you determined it's not working. Also what else are you doing/using?

Wasn't done on purpose, it's just a laptop that happens to have a board running on InsydeH20.. 

 

Removed the emulation driver, stored a new variable in the nvram and restarted the computer to see whether the variable's preserved or not. 

 

What else am I doing/using?

 

0:100  0:000  Starting Clover revision: 4369 on INSYDE Corp. EFI
0:100  0:000  Build with: [Args: -mc | -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE5 -n 5 | OS: 10.13.2 | XCODE: 9.2]

0:145  0:000  KextsToPatch: 7 requested
0:145  0:000   - [00]: com.apple.driver.AirPort.Brcm4360 (Wifi macbook pro whitelist) :: BinPatch :: data len: 20
0:145  0:000   - [01]: com.apple.iokit.IOAHCIBlockStorage (NoLabel) :: BinPatch :: data len: 10
0:145  0:000   - [02]: com.apple.driver.AppleIntelFramebufferCapri (HDMI-video, 64MB BIOS, HD4000 0x01660004 #1 of 2) :: BinPatch :: data len: 12
0:145  0:000   - [03]: com.apple.driver.AppleIntelFramebufferCapri (HDMI-video, 64MB BIOS, HD4000 0x01660004 #2 of 2) :: BinPatch :: data len: 48
0:145  0:000   - [04]: com.apple.driver.AppleIntelFramebufferCapri (HDMI-audio HD4000 0x01660004, port 0205) :: BinPatch :: data len: 12
0:145  0:000   - [05]: com.apple.driver.AppleIntelFramebufferCapri (HDMI-audio HD4000 0x01660004, port 0304) :: BinPatch :: data len: 12
0:145  0:000   - [06]: com.apple.driver.AppleIntelFramebufferCapri (HDMI-audio HD4000 0x01660004, port 0406) :: BinPatch :: data len: 12

1:040  0:000  Beginning FSInjection
FSInjectionInstall ...
- Our FSI_SIMPLE_FILE_SYSTEM_PROTOCOL installed on handle: B780E098
FSInjectionInstall ...
- Our FSI_SIMPLE_FILE_SYSTEM_PROTOCOL installed on handle: B780E098
1:040  0:000  Use origin smbios table type 1 guid.
1:042  0:001  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
1:042  0:000  Extra kext: EFI\CLOVER\kexts\Other\HWInfo.kext (v.1.0.1)
1:049  0:007  Extra kext: EFI\CLOVER\kexts\Other\IntelGraphicsFixup.kext (v.1.2.1)
1:059  0:010  Extra kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext (v.4.6.8)
1:085  0:025    |-- PlugIn kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Controller.kext (v.4.6.8)
1:094  0:008    |-- PlugIn kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Keyboard.kext (v.4.6.8)
1:102  0:008  Extra kext: EFI\CLOVER\kexts\Other\ACPIBacklight.kext (v.3.0.5)
1:113  0:010  Extra kext: EFI\CLOVER\kexts\Other\XHCPlistProperty.kext (v.1.1)
1:118  0:004  Extra kext: EFI\CLOVER\kexts\Other\RealtekRTL8100.kext (v.2.0.0)
1:127  0:009  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.2)
1:137  0:010  Extra kext: EFI\CLOVER\kexts\Other\CodecCommander.kext (v.2.6.2)
1:161  0:023  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.1)
1:174  0:012    |-- PlugIn kext: EFI\CLOVER\kexts\Other\AppleALC.kext\Contents\PlugIns\PinConfigs.kext (v.1.0.0)
1:497  0:323  Extra kext: EFI\CLOVER\kexts\Other\FakeSMC.kext (v.3.5.0)
1:521  0:024  Extra kext: EFI\CLOVER\kexts\Other\ACPIBatteryManager.kext (v.1.81.4)

post-1378824-0-84064200-1515425378_thumb.png

Edited by Needy
Link to comment
Share on other sites

I think this is related to the reserved region. Still haven't fixed it in like the last day....  ^_^

 

EDIT: Did you install the NVIDIA CUDA driver for OpenCL?

 

Yes, all installed, CUDA and WebDriver-378.10.10.10.25.102

 

EDIT: Btw. I now tried slide=1 and slide=128 (CSR 67), regarding that FCPX crash: No change.

Link to comment
Share on other sites

That wasn't directed at you, it was just a general statement. The code base for clover is becoming massive, can't remember every tiny detail of everything done years ago. It needs comments, that's why they exist. And that is slightly more detail than needed, lol. But a summarized version of that without all the actual data (because we are looking for more abstract stuff) would be the correct way to comment. Something like "patching this method for this reason at this place with any relevant notes," like you said above.

 

EDIT: Also it's very important to write when you are unsure of some code or that it might have a side effect. Oh god is that important.

Those docs above were done one year ago, now I even have forgotten the details, but it surely gave me the clearest way to find the new patch (for 10.14?)

I treated the actual data as examples just like what I wrote, that is "You will see something LIKE this".

Whatever the correct way is, I still choose the easiest way for me to understand...

I'm always too lazy to check the patch carefully, maybe I don't even have that ability, lol.

 

EDIT: Sorry I'm going to sleep now, I may check the context later.

Edited by PMheart
  • Like 1
Link to comment
Share on other sites

Guys can anyone please tell me what happened to nvram.plist in the EFI partition? I noticed that it's gone few months ago and I forgot to ask about it. Is it gone because of the new clover versions or we still get it on some builds?

Link to comment
Share on other sites

 

Wasn't done on purpose, it's just a laptop that happens to have a board running on InsydeH20.. 

 

Just making a joke.

 

Removed the emulation driver, stored a new variable in the nvram and restarted the computer to see whether the variable's preserved or not. 

What else am I doing/using?

 

You don't have AptioFix2 in drivers folder.

 

Yes, all installed, CUDA and WebDriver-378.10.10.10.25.102

 

EDIT: Btw. I now tried slide=1 and slide=128 (CSR 67), regarding that FCPX crash: No change.

 

Well if you have the CUDA and web drivers why doesn't your NVIDIA work for OpenCL and hardware decode? Both are definitely supported by 1050Ti, I checked. Which SMBIOS are you using?

 

Guys can anyone please tell me what happened to nvram.plist in the EFI partition? I noticed that it's gone few months ago and I forgot to ask about it. Is it gone because of the new clover versions or we still get it on some builds?

 

You have to have RC scripts installed. You don't need it though if you are using new AptioFix2 and having native NVRAM, which you do right?

Link to comment
Share on other sites

You have to have RC scripts installed. You don't need it though if you are using new AptioFix2 and having native NVRAM, which you do right?

I suppose I do have native nvram on my mobo since I don't use RC Scripts and I have a functional nvram, but I guess there was a time that with a certain BIOS update the nvram was broken so I had to use the RC Scripts to make the nvidia web driver the default driver but not anymore.

 

And yes thanks to you I'm using the new AptioFix2 so with my Skylake rig and I have a very happy hack with SIP fully enabled.

 

But for my second system in the signature I guess things are a little bit different. I might just try to test the new AptioFix2 and see if I can use it on that system as well.

 

I only tired to boot the macOS High Sierra once and I got the notorious Kernel Memory Allocation Error and since I was busy fixing my Skylake rig I didn't go any further.

Link to comment
Share on other sites

Well if you have the CUDA and web drivers why doesn't your NVIDIA work for OpenCL and hardware decode? Both are definitely supported by 1050Ti, I checked. Which SMBIOS are you using?

 

No, man, you misread. nvidia opencl is working fine. hd4600 opencl + nvidia opencl will crash final cut pro x though.

 

Btw. if you want to try a fix, let me know if I can help you with some debug-information.

Link to comment
Share on other sites

I suppose I do have native nvram on my mobo since I don't use RC Scripts and I have a functional nvram, but I guess there was a time that with a certain BIOS update the nvram was broken so I had to use the RC Scripts to make the nvidia web driver the default driver but not anymore.

 

And yes thanks to you I'm using the new AptioFix2 so with my Skylake rig and I have a very happy hack with SIP fully enabled.

 

But for my second system in the signature I guess things are a little bit different. I might just try to test the new AptioFix2 and see if I can use it on that system as well.

 

I only tired to boot the macOS High Sierra once and I got the notorious Kernel Memory Allocation Error and since I was busy fixing my Skylake rig I didn't go any further.

 

Yeah depending on the other firmware it's possible you get the error, but also it might work now. It's worth trying AptioFix2. Don't use AptioFix from the newest package r4369, it has a bug.

No, man, you misread. nvidia opencl is working fine. hd4600 opencl + nvidia opencl will crash final cut pro x though.

 

Btw. if you want to try a fix, let me know if I can help you with some debug-information.

 

Oh so why not just use only NVIDIA OpenCL? If the problem is with the HD4600? At least temporarily. But hold on let me just see if I can fix this now, I don't know why I'm putting it off.

Link to comment
Share on other sites

Yeah depending on the other firmware it's possible you get the error, but also it might work now. It's worth trying AptioFix2. Don't use AptioFix from the newest package r4369, it has a bug.

 

Oh so why not just use only NVIDIA OpenCL? If the problem is with the HD4600? At least temporarily. But hold on let me just see if I can fix this now, I don't know why I'm putting it off.

I'm compiling the r4370 right now and I will give that a try once it's done.

Link to comment
Share on other sites

Just making a joke.

 

 

You don't have AptioFix2 in drivers folder.

Tbf I'm not happy with it either  :D 

 

My system boots fine without it, however, I tried booting with it and there're no changes. I'll try once again just to make sure. 

Link to comment
Share on other sites

Rev 4368, 4369

 

NVRAM and other runtime fixes for AptioFix.

 

Runtime code areas are no longer allowed to be relocated by boot.efi like runtime data areas. Runtime methods for NVRAM variables are shimmed to enable writing into runtime code regions during the methods, then disabled upon return. Native NVRAM should work for everyone now. AptioFix2 should be preferred over AptioFix, but you may need to calculate a slide value for now.

Hi, When you say that the NVRAM should work native for all, what do you mean? that we no longer need to install the RC scripts?

Link to comment
Share on other sites

I'm compiling the r4370 right now and I will give that a try once it's done.

 

Oh there is no difference in the code, only the windows build system for r4370.

 

Tbf I'm not happy with it either  :D 

 

My system boots fine without it, however, I tried booting with it and there're no changes. I'll try once again just to make sure. 

 

Remove EmuVar driver and use AptioFix2 driver from at least r4369, have native NVRAM.

 

Hi, When you say that the NVRAM should work native for all, what do you mean? that we no longer need to install the RC scripts?

 

Remove EmuVar driver and use AptioFix2 driver from at least r4369, have native NVRAM. No RC scripts, unless you want them for some other reason.

Link to comment
Share on other sites

not valid for all..I mean for my x99 rig it is not working :-(

 

 

 

 

Remove EmuVar driver and use AptioFix2 driver from at least r4369, have native NVRAM. No RC scripts, unless you want them for some other reason.

Link to comment
Share on other sites

Oh there is no difference in the code, only the windows build system for r4370.

Well too late :P , I just updated my clover to r4370 and AptioFix2 is working perfect on my IvyBrige rig as well with CsrConfig=0x0

  • Like 1
Link to comment
Share on other sites

not valid for all..I mean for my x99 rig it is not working :-(

 

Please give me memmap from EFI shell after clover GUI and boot.log (or debug.log) when using AptioFix2 from at least r4369.

 

Btw. if you want to try a fix, let me know if I can help you with some debug-information.

 

Please try this AptioFix2 and let me know results. Could be a disaster... Could work.

OsxAptioFix2Drv-64.efi

Link to comment
Share on other sites

how to store on file memmap result? (sorry for noob question)

 

 
Please give me memmap from EFI shell after clover GUI and boot.log (or debug.log) when using AptioFix2 from at least r4369.

 

 
Please try this AptioFix2 and let me know results. Could be a disaster... Could work.

Link to comment
Share on other sites

Yes you need to enter a slide value sometimes to get AptioFix2 to work. Maybe it should be modified to determine that on it's own. I want to obsolete AptioFix.... Make AptioFix2 the one method to rule them all! Also rename it.... lol

 

EDIT: Test the newest AptioFix2 and see what the result is. Using a slide is not a big deal, it's done anyway to place the kernel.

 

 

The newest AptioFix2 from r4369 should be very different than the previous and should give you very close to 100% working system besides a few caveats that still need fixed but I want to get rid of AptioFix and rename AptioFix2 to something more appropriate. There should not be a need for AptioFix anymore as AptioFix2 should be sufficiently modified to work for every system. Or at least I hope.

Also everyone testing this driver, if you have EmuVar driver remove that because you should have working NVRAM.

 

Thanks for posing a real world example of calculating slide. I understand that now.

 

However, won't the slide memmap (and hence optimal slide value) change everytime I add/remove a PCI-e device? I change those around quite frequently for work, and often have 5+ PCI-e slots occupied.

Link to comment
Share on other sites

×
×
  • Create New...