Clover General discussion

[cecekpawon]

I wanted to install the beta 5 of 10.13.1 and ran into some issues with r4265:

 

>>>

 

Which mean Clover need more installer version plist paths to read

[Slice]

>>>

 

Which mean Clover need more installer version plist paths to read

>>>>

already done

[cecekpawon]

Understood Slice, its fallback when Clover cant found any known version plist. FYI I have \.IABootFilesSystemVersion.plist on my initial 10.13 installer. Lets see what happen next if we uncomment this block of code

[apianti]

i made Darwin do a dump over here http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2522249

 

i think everything but the screenshots are in that darwin's dump =0) please correct me if i'm wrong.

 

the error happens instantly in memtest/rember displaying that text

 

all the other occurences are hard to screenshot, like finder getting stuck, resolve render output getting corrupted, or prefence files getting messed up up to the point of the system becoming unbootable (the reason i started testing initially)

 

i can only reproduce this problem by having usb drive devices attached. so i believe that yes, only usb related

 

dumping the original acpi tables is going to take some time, i am away from the machine now. i can, however, try to get a darwin dump with the original acpi tables from a similar setup, if my Darwin's dump is of no help without the original unpatched tables. I don't use a custom, only the patches that are in the plist an i believe that clover drops most of the secondary

 

Ok just looking at your log, you have some crazy issues:

0:100  0:000  CPU was calibrated without ACPI PM Timer: ACPI I/O space is not enabled., use RTC

Try using the UEFI only options when installing, it looks like you have some legacy or custom build.

0:100  0:000  Build with: [Args: -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8 | -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 9 | OS: 10.12.6 | XCODE: 9.0]

Very very unsupported CPU.

0:102  0:000  CPU Vendor = 756E6547 Model=50654
...
0:102  0:000  BrandString = Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz

You may need to adjust some settings in your firmware setup menu as there are many disabled devices:

0:102  0:000  PCI (00|00:05.01) : FFFF FFFF class=FFFFFF

Is this fake CPU capable of working with your CPU? Have you tried others?

0:119  0:000  FakeCPUID: 506E4

Are these patches 100% correct and needed? Have you tried built-in XCPM enabling?

0:119  0:000  KextsToPatch: 3 requested
0:119  0:000   - [00]: AppleUSBXHCIPCI (Remove Port Limit) :: BinPatch :: data len: 7
0:119  0:000   - [01]: IOAHCIBlockStorage (SSD Trim Enabler) :: BinPatch :: data len: 10
0:119  0:000   - [02]: AppleUSBXHCIPCI (USB Port Limit Patch) :: BinPatch :: data len: 4
0:119  0:000  KernelToPatch: 8 requested
0:119  0:000   - [00]: xcpm_cpuid_set_info © Pike R. Alpha :: MatchOS: 10.13.x :: data len: 8
0:119  0:000   - [01]: xcpm_bootstrap Sierra © Pike R. Alpha :: MatchOS: 10.13.x :: data len: 8
0:119  0:000   - [02]: xcpm_program_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 28
0:119  0:000   - [03]: xcpm_pkg_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 12
0:119  0:000   - [04]: xcpm_SMT_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 11
0:119  0:000   - [05]: xcpm_core_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 12
0:119  0:000   - [06]: xcpm_idle patch by Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 7
0:119  0:000   - [07]: 10.13 Installer/Updater essential :: MatchOS: 10.12.x,10.13.x :: data len: 11

There were no RAM modules found on the SMBus controller... Not sure why it wouldn't find the four modules you have installed.

1:040  0:000  SMBus device : 8086 A2A3 class=0C0500 status=Success
1:040  0:000  SMBus CmdReg: 0x3
1:040  0:000  Scanning SMBus [8086:A2A3], mmio: 0x3FF44004, ioport: 0x3000, hostc: 0x11
1:040  0:000  Slots to scan [8]...

Whoa. Nice frequency! That's fast.

5:907  0:000  Finally: ExternalClock=25MHz BusSpeed=100377kHz CPUFreq=-4294963984MHz PIS: hw.busfrequency=100000000Hz

This is also not correct, there should be four device mappings here since you have four modules. Also the mappings don't make sense, this means that less than 48MB is mapped and overlapping. I have a feeling this is where your problem may be starting.

6:045  0:000  NumberOfMemoryDevices = 8
6:045  0:000  Type20[0]->End = 0xFFFFFF, Type17[0] = 0x4000
6:045  0:000  Type20[1]->End = 0x1FFFFFF, Type17[1] = 0xC000
6:045  0:000  Type20[2]->End = 0x2FFFFFF, Type17[2] = 0x18000

Are you sure you want to drop these tables entirely? You aren't reinjecting any

6:061  0:000  Drop tables from Xsdt, SIGN=DMAR TableID=A M I  Length=216
6:061  0:000   Xsdt has tables count=30
6:061  0:000   Table: DMAR  A M I   216 dropped
6:061  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=PtidDevc Length=12290
6:061  0:000   Xsdt has tables count=29
6:061  0:000   Table: SSDT  PtidDevc  12290 dropped
6:061  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=sensrhub Length=671
6:061  0:000   Xsdt has tables count=28
6:061  0:000   Table: SSDT  sensrhub  671 dropped

I think you may have some trouble with the number of cores that CPU has. Also don't generate p and c states, patch your existing tables, drop the originals and reinject the patched.

6:062  0:000  Out of control with CPU numbers
6:062  0:000  CPUBase=0 and ApicCPUBase=0 ApicCPUNum=20
6:062  0:000  Maximum control=0x21
6:062  0:000  Turbo control=0x2B
6:062  0:000  P-States: min 0xC, max 0x2B
6:062  0:000  SSDT with plugin-type without P-States is generated
6:062  0:000  SSDT with CPU C-States generated successfully

Remove most of these from injection, leave FakeSMC and install the rest properly. Why do you have VoodooTSCSync? Get rid of that evil monstrosity.

6:068  0:002  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
6:068  0:000  Extra kext: EFI\CLOVER\kexts\Other\VoodooTSCSync.kext
6:074  0:006  Extra kext: EFI\CLOVER\kexts\Other\FakeSMC.kext
6:081  0:006  Extra kext: EFI\CLOVER\kexts\Other\ACPISensors.kext
6:086  0:005  Extra kext: EFI\CLOVER\kexts\Other\NvidiaGraphicsFixup.kext
6:092  0:006  Extra kext: EFI\CLOVER\kexts\Other\GPUSensors.kext
6:100  0:007  Extra kext: EFI\CLOVER\kexts\Other\IntelMausiEthernet.kext
6:105  0:005  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext
6:113  0:008    |-- PlugIn kext: EFI\CLOVER\kexts\Other\AppleALC.kext\Contents\PlugIns\PinConfigs.kext
6:119  0:006  Extra kext: EFI\CLOVER\kexts\Other\SmallTreeIntel82576.kext
6:125  0:005  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext
6:130  0:004  Extra kext: EFI\CLOVER\kexts\Other\LPCSensors.kext
6:140  0:009  Extra kext: EFI\CLOVER\kexts\Other\ATTOExpressPCI4.kext

Turn off custom boot logo. I never finished it and I'm not sure it doesn't cause side effects.

6:150  0:000  Custom boot is using apple logo
6:153  0:003  Custom boot lock
6:153  0:000  Custom boot framebuffer 0xC0000000 0x900000
6:153  0:000  Custom boot GOP: 0x39239498 @0xC0900000 0x300000 1024(1024)x768

[bronxteck]

Lilu and its plugins are designed to run from clover not S/L/E. to run it "correctly" as you mention you would need yet another kext called lilu friend

[apianti]

Lilu and its plugins are designed to run from clover not S/L/E. to run it "correctly" as you mention you would need yet another kext called lilu friend

 

Ummmmm no, http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2371334

 

EDIT: Oh I see what you mean, that a few of the plugins don't work unless injected. But that's really on the person who developed them because every kext should work when installed....

[tluck]

been trying to follow the thread on kext injection vs install in /L/E

for many years now, I have installed a duplicate set of kexts one set in ESP...Other and then install them in /L/E

 

Question: what is the downside of NOT having custom kexts in /L/E?

 

I observe (my experience with High Sierra and Clover 4267) with these 2 scenarios:

 

ESP

Clover injects all custom kexts (whether binary or just "property injectors") including Lilu/AppleALC

- SIP can be fully enabled

- ESP kexts provide support for installer and/or Recovery

- Note: can run OS fine too - all kexts work. 

 

Custom kexts in /Library/Extensions 

- SIP must be (partially or fully) disabled - due to kext signing etc.

- use detect kext feature

 

list of kexts:

• ACPIBatteryManager.kext
• ACPIPoller.kext
• Lilu.kext+AppleALC.kext
• AppleBacklightInjector.kext
• BlueTooth_Injector_T420.kext
• EFICheckDisabler.kext
• FakeSMC.kext + plugins
• IOAHCIBlockStorageInjector.kext
• IntelMausiEthernet.kext
• VoodooPS2Controller.kext

[vit9696]

Ummmmm no, http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2371334

 

EDIT: Oh I see what you mean, that a few of the plugins don't work unless injected. But that's really on the person who developed them because every kext should work when installed....

Incorrect. When you install a kext into /S/L/E or /L/E macOS does not guarantee you any load priority unless you are an apple kext with apple security extension flag.

Lilu needs to start very early to be able to attach to a certain MAC policy to enable kext patcher/process patcher.

If you install it without LiluFriend (which is marked as apple security and has Lilu with plugins as a dependency) approximately 10-15% of kextcache rebuilds will result in Lilu and (obviously all the plugins) not loading in the system.

[apianti]

Incorrect. When you install a kext into /S/L/E or /L/E macOS does not guarantee you any load priority unless you are an apple kext with apple security extension flag.

Lilu needs to start very early to be able to attach to a certain MAC policy to enable kext patcher/process patcher.

If you install it without LiluFriend (which is marked as apple security and has Lilu with plugins as a dependency) approximately 10-15% of kextcache rebuilds will result in Lilu and (obviously all the plugins) not loading in the system.

 

I was pointing out that you specifically said that it was not boot loader dependent and he said that it was designed to run from clover. Just a thought, why not just use IOPCIMatch for any Intel (and/or AMD) device...? Then it will always load... How is injecting giving you any better load priority? Wouldn't it initialize the prelinked data already there then load the kext from the datahub?

[vit9696]

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

[apianti]

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

 

I think I'm just lazy and wasn't clear:

 

Lilu and its plugins are designed to run from clover

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

 

No, I understood, I was asking a question about why it wouldn't be initializing the prelinked kexts before the injected. Also seems like a pretty big security flaw, if they are indeed not even checked when sip is enabled.

[vit9696]

Well, this question should be asked at lists.apple.com at Darwin-Kernel. The ones in the beginning of the prelinked list are also fine, but there is no deterministic way to get there.

 

As for security flaws, this is actually a bit more secure, because this way you cannot really use Lilu unless you loaded the plugin with the system.

[griven]

I guess vit9696 is right since Apple relies on it´s ecosystem. All the things we do on bootloader level are hackintosh specific since they take place before macOS takes over. Stuff like kext injection will most likely not work on real macs since there is no layer between the machines EFI and the oses boot.efi which could enable manipulation of the Memmap in any way. Given that there is no need to double check if extensions which are part of the prelinked kernel are signed or not since they will only find their way into it if they are signed or if the user decided to disable SIP to allow loading of unsigned Extensions. 

[RehabMan]

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

 

It seems that kexts placed in /L/E generally go to the beginning of the prelink.  I think kextcache scans there first.

So you can probably use Lilu and plugins if you install to /L/E instead of /S/L/E without requiring LiluFriend.

[mhaeuser]

Stuff like kext injection will most likely not work on real macs since there is no layer between the machines EFI and the oses boot.efi which could enable manipulation of the Memmap in any way. Given that there is no need to double check if extensions which are part of the prelinked kernel are signed or not since they will only find their way into it if they are signed or if the user decided to disable SIP to allow loading of unsigned Extensions. 

Rubbish, kext injection happens after boot.efi starts, anything else wouldn't make any sense. Injecting kexts on a Mac would work the very way Clover does it.

[PMheart]

Hi.

 

New bios release date of Macmini7,1 found, thanks Pike for his article. (https://pikeralpha.wordpress.com/2017/10/26/high-sierra-dpbeta-10-13-1-build17b46a-seeded/)

 

So. This line (https://sourceforge.net/p/cloverefiboot/code/4269/tree/rEFIt_UEFI/Platform/platformdata.c#l95), please change to

MM71.88Z.0226.B00.1709290808

Thanks in advance.

[apianti]

It seems that kexts placed in /L/E generally go to the beginning of the prelink.  I think kextcache scans there first.

So you can probably use Lilu and plugins if you install to /L/E instead of /S/L/E without requiring LiluFriend.

 

Hmmmmm....

 

Rubbish, kext injection happens after boot.efi starts, anything else wouldn't make any sense. Injecting kexts on a Mac would work the very way Clover does it.

 

Yeah, the kernel is loading these kexts, so it happens on any real mac as well. It's a blaring security hole, which you could use to bypass SIP apparently. If you had a USB drive with a simple EFI application that just injects a malicious kext, finds boot.efi and chainloads. All you need to do is boot from the USB...

[Slice]

I have to remind that vanilla system (10.11+) is not loading separate kexts. It is Clover patch to do this. Vanilla system always use cache.

[PMheart]

I have to remind that vanilla system (10.11+) is not loading separate kexts. It is Clover patch to do this. Vanilla system always use cache.

Why? I think patching "__ZN12KLDBootstrap21readStartupExtensionsEv" will do the trick, which is also now what Clover is using. (See *EXT patches in kext_inject.c)

If I remember correctly, we have had to also patch "__ZN6OSKext14loadExecutableEv" as of 10.11 due to SIP. (See *SIP patches in kext_inject.c)

[vit9696]

It seems that kexts placed in /L/E generally go to the beginning of the prelink.  I think kextcache scans there first.

So you can probably use Lilu and plugins if you install to /L/E instead of /S/L/E without requiring LiluFriend.

Again incorrect, though indeed it increases the probability, since there are less kexts in /L/E, and scandir may return Lilu and friends earlier. But this is not what happens after you install another kext there, and if it requires many dependencies, you are screwed.

 

It is not like I did not want to allow /L/E or /S/L/E as is, it is simply something I could not have done.

[RehabMan]

Again incorrect, though indeed it increases the probability, since there are less kexts in /L/E, and scandir may return Lilu and friends earlier. But this is not what happens after you install another kext there, and if it requires many dependencies, you are screwed.

 

It is not like I did not want to allow /L/E or /S/L/E as is, it is simply something I could not have done.

The kexts you have in /L/E are generally hack kexts, and therefore not subject to patching by Lilu.

I've been installing Lilu.kext + IntelGraphicsFixup.kext into /L/E for some time (no LiluFriend) and it is working just fine.

So I guess I'm on the lucky side of this one.

Using LiluFriend would be the first thing I would try *if* I ran into an issue.

YMMV.

[vit9696]

It is not a problem of "patching" the kexts by in /L/E (and in any case they are usually kexts for 3rd party software and not necessarily for hack), but a problem of kexts requiring dependencies that take a lot of time to load and thus effectively making Lilu load after MAC policy initialisation completes in XNU.

You indeed are lucky, but if you try commands like "sudo touch /System/Library/Extensions && sudo touch /Library/Extensions && sudo reboot" like 4-5 times in a row you will be surprised.

[RehabMan]

It is not a problem of "patching" the kexts by in /L/E (and in any case they are usually kexts for 3rd party software and not necessarily for hack), but a problem of kexts requiring dependencies that take a lot of time to load and thus effectively making Lilu load after MAC policy initialisation completes in XNU.

You indeed are lucky, but if you try commands like "sudo touch /System/Library/Extensions && sudo touch /Library/Extensions && sudo reboot" like 4-5 times in a row you will be surprised.

 

I do rebuild cache (kextcache -i /) any time I build/install a new kext.

I'll let you know when I'm "unlucky".

[Vinicius P. Miranda]

Guys, I'm a little lost, I do not know if this is the right place to post this question, anything is just informing me that I delete de post.

 

With the arrival of High Sierra, people who have Fusion Drive began to have errors like me, the system installs, but when it reboots, there does not appear in the Clover the option to boot in the correct place to finish the installation.

When an update came out in early October, I upgraded the system, and also could not log in anymore because the partition did not appear on the clover screen so I could log in.

 

This only happens with Fusion Drive. I dismounted and mounted mine several times, changed the SSD too, and still the problem persisted.

I'm afraid the same thing will happen in a future update.

I wonder, is this a problem with Clover? Do the developers know that this error exists?

[Slice]

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

 

Explain, please, what do you mean "load priority"?

All kexts already loaded into memory.

Then they performs Init() method.

Then they performs Probe() method and return successful or not to try again after other kexts run. There is ProbeScore number.

Then they started  one by one.

All you need is Lilu started first? There is no direct dependency from where it is loaded. It is loaded in memory.

What if a kext to be patched does something at Probe() method? Lilu started after that because Start() method works after all Probe() methods.