Clover General discussion

[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.

[vit9696]

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.

 

 I/O Kit init/probe/start methods are not the first methods called within a kext. There also is a kmod interface, that is called much earlier, right after kext loading (unlike init/start which are asynchronous in its nature).

 

https://opensource.apple.com/source/xnu/xnu-4570.1.46/libsa/bootstrap.cpp.auto.html

 

Check: KLDBootstrap::readStartupExtensions (it is defined as record_startup_extensions_function). This clears what the order is. Booter kexts are added to the beginning of the list of kexts that are to be processed, and their kmod interface is guaranteed to be called earlier.

 

Then check KLDBootstrap::loadKernelComponentKexts in the same file, it shows that the first kexts to load are the ones being basic platform <library> kexts (e.g. System.kext and so on, see sKernelComponentNames). 

Then there are com.apple.kec. kexts (external components), which provide crypto, threads and stuff (e.g. com.apple.kec.corecrypto, com.apple.kec.Libm, etc.)

Then we have device tree update…

 

record_startup_extensions_function is called before I/O Kit is fully initialised (https://opensource.apple.com/source/xnu/xnu-4570.1.46/iokit/Kernel/IOStartIOKit.cpp) and then the asynchronous kext loading from the list happens in the following order: booter kexts, prelinked cache, everything else kextd asks to load.

 

However, there is an exception called KLDBootstrap::loadSecurityExtensions.

https://opensource.apple.com/source/xnu/xnu-4570.1.46/security/mac_base.c.auto.html

Check: mac_policy_initmach

 

Which basically overrides the order as it is, and forces security extensions to load here and now as we need MAC policy.

 

This should be enough to understand the cause, and if you are really interesting in the details, you could check the code further starting from the functions I mentioned.

[Sherlocks]

@Slice

today, i tested EDID injection.

clover now use AAPL00,override-no-edid for Fake EDID injection. it works on 10.8~10.13.

but on 10.6.8 and 10.7.5, this key is not work. always use system's original edid value. 

i checked intel AppleIntelSNBGraphicsFB binary.

there are some key for edid. but i tested these keys are not work.

AAPL00,override-no-edid <-now use in clover

AAPL00,override-no-connect

AAPL00,override-has-edid

AAPL00,override-no-edid

AAPL00,override-has-edid-digital

 

AAPL01 also exist. but no luck. now must be add edid as manual in S/L/Display/Overrides on 10.6.8 and 10.7.5

 

do you have any idea? how about your Dell Latitude D430's edid injection on 10.7.5?

 

thanks in advance

AppleIntelSNBGraphicsFB.zip

[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.

 

What if Lilu.kext and all Lilu plugins were made bundle-id: com.apple.security.*

Problem?

[vit9696]

That works fine (though additionally needs AppleSecurityExtension set to YES in Info.plist), and that is basically what LiluFriend does. I feel bad for doing this for non-apple kexts though, plus apple could always check for non-apple signature if it sees such an id.

[RehabMan]

That works fine (though additionally needs AppleSecurityExtension set to YES in Info.plist), and that is basically what LiluFriend does. I feel bad for doing this for non-apple kexts though, plus apple could always check for non-apple signature if it sees such an id.

 

IMHO, seems like a good thing to do for all Lilu+plugins.

 

Any such Apple check would break LiluFriend as well, so... the solutions are equal that way, except that it removes the burden from the user to create custom LiluFriend.kext, and places the burden back on the Lilu-based kext developer (where it belongs).