Clover Problems and Solutions

apianti · October 10, 2017

Well, of course it uses the LockBox...

DXE driver writes a Boot Script -> BootScriptLib saves the data to LockBox -> reset -> PEIM retrieves lock box -> DXE executes Boot Scripts and resumes.

I guess I am not being clear enough or something. That's only valid for EDK2 based firmware. You don't know how the firmware actually performs this, maybe it doesn't use SMM and instead uses some internal stuff in NVRAM/ROM. Since you don't know how the firmware actually stores the boot script table, you using that code means you have to change the DXE driver for S3 so that you do know how it's stored - in an SMM lock box. You changing that S3 DXE driver means you also have to change the S3 PEI driver because you can't be sure the method that is being used store/retrieve the boot script table otherwise. If you store in an SMM lock box and the PEI driver doesn't read from there to restore then it's useless. Is that clearer for what I'm trying to say?

Zenith432 · October 16, 2017

In Clover's Kext Patcher, there is an option to patch a kext's Info.plist with

<key>InfoPlistPatch</key>
<true/>

Unfortunately, for kexts packed in prelinkedkernel this feature is nearly useless. Because the Info.Plist used is the one placed inside __PRELINK_INFO segment of the prelinked kernel.

For example, here's the full Info.plist for AppleHDAController

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildMachineOSBuild</key>
	<string>16B2657</string>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>AppleHDAController</string>
	<key>CFBundleGetInfoString</key>
	<string>AppleHDAController 280.12, Copyright © 2000-2017 Apple Inc. All rights reserved.</string>
	<key>CFBundleIdentifier</key>
	<string>com.apple.driver.AppleHDAController</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>HDA Controller Driver</string>
	<key>CFBundlePackageType</key>
	<string>KEXT</string>
	<key>CFBundleShortVersionString</key>
	<string>280.12</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleSupportedPlatforms</key>
	<array>
		<string>MacOSX</string>
	</array>
	<key>CFBundleVersion</key>
	<string>280.12</string>
	<key>DTCompiler</key>
	<string>com.apple.compilers.llvm.clang.1_0</string>
	<key>DTPlatformBuild</key>
	<string>9M189u</string>
	<key>DTPlatformVersion</key>
	<string>GM</string>
	<key>DTSDKBuild</key>
	<string>17A356</string>
	<key>DTSDKName</key>
	<string>macosx10.13internal</string>
	<key>DTXcode</key>
	<string>0900</string>
	<key>DTXcodeBuild</key>
	<string>9M189u</string>
	<key>IOKitPersonalities</key>
	<dict>
		<key>BuiltInHDA</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleHDAController</string>
			<key>CodecAddressFilterArray</key>
			<array>
				<dict>
					<key>CodecAddressMask</key>
					<data>
					AQAAAA==
					</data>
					<key>LayoutID</key>
					<integer>16392</integer>
					<key>PCIVendorDeviceID</key>
					<integer>282987200</integer>
				</dict>
				<dict>
					<key>CodecAddressMask</key>
					<data>
					AQAAAA==
					</data>
					<key>LayoutID</key>
					<integer>0</integer>
					<key>PCIVendorDeviceID</key>
					<integer>282987200</integer>
				</dict>
				<dict>
					<key>CodecAddressMask</key>
					<data>
					CQAAAA==
					</data>
					<key>LayoutID</key>
					<integer>65</integer>
					<key>PCIVendorDeviceID</key>
					<integer>282987200</integer>
				</dict>
				<dict>
					<key>CodecAddressMask</key>
					<data>
					AQAAAA==
					</data>
					<key>LayoutID</key>
					<integer>73</integer>
					<key>PCIVendorDeviceID</key>
					<integer>282987200</integer>
				</dict>
			</array>
			<key>DPAlwaysDisplayRouting</key>
			<array>
				<integer>3</integer>
				<integer>33</integer>
				<integer>35</integer>
				<integer>88</integer>
			</array>
			<key>DPAudioDeviceExclusion</key>
			<array>
				<dict>
					<key>ManufacturerID</key>
					<integer>1552</integer>
					<key>ProductID</key>
					<integer>10130</integer>
				</dict>
			</array>
			<key>HighFIFOLimitSupport</key>
			<array/>
			<key>HwFactoryPrefixTranslation</key>
			<array>
				<dict>
					<key>LayoutID</key>
					<integer>78</integer>
					<key>SourceDID</key>
					<integer>43584</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>78</integer>
					<key>SourceDID</key>
					<integer>43576</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>79</integer>
					<key>SourceDID</key>
					<integer>43584</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>79</integer>
					<key>SourceDID</key>
					<integer>43576</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
			</array>
			<key>IOClass</key>
			<string>AppleHDAController</string>
			<key>IOPCIClassMatch</key>
			<string>0x04010000&0xFFFD0000</string>
			<key>IOProviderClass</key>
			<string>IOPCIDevice</string>
			<key>RequireMaxBusStall</key>
			<array>
				<dict>
					<key>Layouts</key>
					<array/>
					<key>MaxBusStall</key>
					<integer>15000</integer>
				</dict>
			</array>
		</dict>
		<key>BuiltInHDA9D70</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleHDAController</string>
			<key>DPAlwaysDisplayRouting</key>
			<array>
				<integer>3</integer>
				<integer>33</integer>
				<integer>35</integer>
				<integer>88</integer>
			</array>
			<key>DPAudioDeviceExclusion</key>
			<array>
				<dict>
					<key>ManufacturerID</key>
					<integer>1552</integer>
					<key>ProductID</key>
					<integer>10130</integer>
				</dict>
			</array>
			<key>HighFIFOLimitSupport</key>
			<array/>
			<key>HwFactoryPrefixTranslation</key>
			<array>
				<dict>
					<key>LayoutID</key>
					<integer>78</integer>
					<key>SourceDID</key>
					<integer>43584</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>78</integer>
					<key>SourceDID</key>
					<integer>43576</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>79</integer>
					<key>SourceDID</key>
					<integer>43584</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
				<dict>
					<key>LayoutID</key>
					<integer>79</integer>
					<key>SourceDID</key>
					<integer>43576</integer>
					<key>StandInDID</key>
					<integer>43568</integer>
					<key>VID</key>
					<integer>4098</integer>
				</dict>
			</array>
			<key>IOClass</key>
			<string>AppleHDA8086_9D70Controller</string>
			<key>IONameMatch</key>
			<array>
				<string>pci8086,9d70</string>
			</array>
			<key>IOProbeScore</key>
			<integer>2</integer>
			<key>IOProviderClass</key>
			<string>IOPCIDevice</string>
			<key>RequireMaxBusStall</key>
			<array>
				<dict>
					<key>Layouts</key>
					<array/>
					<key>MaxBusStall</key>
					<integer>15000</integer>
				</dict>
			</array>
		</dict>
	</dict>
	<key>NSHumanReadableCopyright</key>
	<string>AppleHDAController 280.12, Copyright © 2000-2017 Apple Inc. All rights reserved.</string>
	<key>OSBundleCompatibleVersion</key>
	<string>1.0.0d1</string>
	<key>OSBundleLibraries</key>
	<dict>
		<key>com.apple.iokit.IOAudioFamily</key>
		<string>200.5</string>
		<key>com.apple.iokit.IOGraphicsFamily</key>
		<string>2.0</string>
		<key>com.apple.iokit.IOHDAFamily</key>
		<string>265.88</string>
		<key>com.apple.iokit.IOPCIFamily</key>
		<string>1.1</string>
		<key>com.apple.kpi.bsd</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.iokit</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.libkern</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.mach</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.private</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.unsupported</key>
		<string>12.0</string>
	</dict>
</dict>
</plist>

and here's what's found inside __PRELINK_INFO

<dict>
	<key>CFBundleName</key>
	<string>HDA Controller Driver</string>
	<key>DTXcode</key>
	<string>0900</string>
	<key>DTSDKName</key>
	<string>macosx10.13internal</string>
	<key>NSHumanReadableCopyright</key>
	<string>AppleHDAController 280.12, Copyright © 2000-2017 Apple Inc. All rights reserved.</string>
	<key>_PrelinkExecutableLoadAddr</key>
	<integer size="64">0xffffff7f82739000</integer>
	<key>_PrelinkKmodInfo</key>
	<integer size="64">0xffffff7f8274ec80</integer>
	<key>DTSDKBuild</key>
	<string>17A356</string>
	<key>_PrelinkExecutableSize</key>
	<integer IDREF="133"/>
	<key>CFBundleDevelopmentRegion</key>
	<string IDREF="1"/>
	<key>CFBundleVersion</key>
	<string>280.12</string>
	<key>BuildMachineOSBuild</key>
	<string>16B2657</string>
	<key>_PrelinkExecutableSourceAddr</key>
	<integer size="64">0xffffff80029ce000</integer>
	<key>CFBundlePackageType</key>
	<string>KEXT</string>
	<key>CFBundleShortVersionString</key>
	<string>280.12</string>
	<key>CFBundleSupportedPlatforms</key>
	<array>
		<string>MacOSX</string>
	</array>
	<key>OSBundleCompatibleVersion</key>
	<string>1.0.0d1</string>
	<key>_PrelinkExecutableRelativePath</key>
	<string>Contents/MacOS/AppleHDAController</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string IDREF="2"/>
	<key>CFBundleExecutable</key>
	<string>AppleHDAController</string>
	<key>DTCompiler</key>
	<string IDREF="9"/>
	<key>CFBundleIdentifier</key>
	<string>com.apple.driver.AppleHDAController</string>
	<key>DTPlatformVersion</key>
	<string IDREF="10"/>
	<key>DTXcodeBuild</key>
	<string>9M189u</string>
	<key>CFBundleSignature</key>
	<string IDREF="3"/>
	<key>OSBundleLibraries</key>
	<dict>
		<key>com.apple.kpi.bsd</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.libkern</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.mach</key>
		<string>8.0.0</string>
		<key>com.apple.iokit.IOPCIFamily</key>
		<string>1.1</string>
		<key>com.apple.kpi.iokit</key>
		<string>8.0.0</string>
		<key>com.apple.iokit.IOAudioFamily</key>
		<string>200.5</string>
		<key>com.apple.iokit.IOHDAFamily</key>
		<string>265.88</string>
		<key>com.apple.iokit.IOGraphicsFamily</key>
		<string IDREF="30"/>
		<key>com.apple.kpi.unsupported</key>
		<string>12.0</string>
		<key>com.apple.kpi.private</key>
		<string>8.0.0</string>
	</dict>
	<key>CFBundleGetInfoString</key>
	<string>AppleHDAController 280.12, Copyright © 2000-2017 Apple Inc. All rights reserved.</string>
	<key>_PrelinkBundlePath</key>
	<string>/System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/AppleHDAController.kext</string>
	<key>DTPlatformBuild</key>
	<string>9M189u</string></dict>
</dict>

The section IOKitPersonalities is missing, which is the most useful part to patch.

The personalities for kexts are cached in

/System/Library/Caches/com.apple.kext.caches/Startup/IOKitPersonalities_x86_64.ioplist.gz

which is only loaded by the kernel after starting.

Slice · October 19, 2017

@fabiosun

Your posts moved to General Discussion. This topic is for developers.

PMheart · October 19, 2017

Hi, a bit off-topic:

In this line: https://sourceforge.net/p/cloverefiboot/code/4256/tree//rEFIt_UEFI/Platform/kernel_patcher.c#l1879

Better to use DBG_RT() for consistency...

And also. The code somehow doesn't look healthy to me. Under "switch (gCPUStructure.Model)" branch, if a "stupid" (no offense) user enable "KernelXCPM" by accident and his/her CPU is supported natively (e.g. Haswell/Broadwell, etc), then HaswellLowEndXCPM patch will get applied...

Slice · October 20, 2017

Hi, a bit off-topic:

In this line: https://sourceforge.net/p/cloverefiboot/code/4256/tree//rEFIt_UEFI/Platform/kernel_patcher.c#l1879

Better to use DBG_RT() for consistency...

And also. The code somehow doesn't look healthy to me. Under "switch (gCPUStructure.Model)" branch, if a "stupid" (no offense) user enable "KernelXCPM" by accident and his/her CPU is supported natively (e.g. Haswell/Broadwell, etc), then HaswellLowEndXCPM patch will get applied...

Agree about DBG_RT, fixed.

      switch (gCPUStructure.Model) {
...
          default:
            if (gCPUStructure.Model >= CPU_MODEL_HASWELL &&
               (AsciiStrStr(gCPUStructure.BrandString, "Celeron") || AsciiStrStr(gCPUStructure.BrandString, "Pentium"))) {
              // Haswell+ low-end CPU
              EnableExtCpuXCPM = HaswellLowEndXCPM;
            }
            break;

It will be for Haswell Celeron of higher Celeron.

Else EnableExtCpuXCPM == NULL (? - I wish duplicate it)

RehabMan · October 21, 2017

The commit for r4242 breaks InjectKexts=Detect.

When InjectKexts=Detect and FakeSMC.kext is in the kernel cache, no kexts from EFI/Clover/kexts should be injected.

And there's more.

Even with that fixed (reverted), still kexts are being injected with Detect and FakeSMC.kext installed.

I'll try to figure out why (probably this new "kext management" stuff is the problem).

But yeah, InjectKexts=Detect is broken.

cecekpawon · October 21, 2017

Check here.

apianti · October 21, 2017

Slice, unsure why you removed that search for FakeSMC. There was always ability to disable kext injection, now each kext can be disabled individually. The behavior by the Detect value was that kexts are injected if there is no FakeSMC in the cache. This is to provide different behavior for installers and system volumes with no kexts installed, and system volumes with kexts installed. This is to prevent having to use multiple instances of clover, one that has injection and one that doesn't, say if you have an install already but want to create another.

EDIT: I guess what you're saying is go through, disable all of them and it's the same behavior? That seems like a lot more work though...
EDIT2: Also that code is atrocious... -1 and -2 offsets? Why wouldn't it just find every "<" and then check if it ended with "dict>" or "/dict>"... lol

EDIT3: @RehabMan, You need to revert multiple sources to fix it: https://sourceforge.net/p/cloverefiboot/code/4242/

RehabMan · October 21, 2017

EDIT3: @RehabMan, You need to revert multiple sources to fix it: https://sourceforge.net/p/cloverefiboot/code/4242/

I know. But even with both changes, not enough. New code for "kext management" stuff is interfering I think.

I was going to work on it, but then I got caught in a quagmire of trying to make the Esc key do the right thing (that one has bugged me for a long time).

Are we having fun yet?

apianti · October 21, 2017

Entirely possible that it's broken because of that, I'm not exactly sure why it was even necessary to provide such detailed kext injection disabling... Who's injecting that many kexts? I have FakeSMC and that's it... I install the rest I want after the OS. I think they don't understand that the injection is meant to be used in situations where you can't install kexts... But eh. As for trying to figure out anything with the GUI, good luck with that. There's so many random loops inside of each other because the GUI (rEFIt) was badly designed from the start (sorry Christoph!)... Granted, I think Clover has pushed it beyond the breaking point. But GUIs should have only one loop that draws, handles input and dispatches it accordingly.. A single task GUI can be easily implemented with a stack of "screens" that are drawn so the loop just walks down the stack until it reaches a fullscreen "screen" then walks back up the stack drawing each "screen". Entering a menu just pushes that menu onto the top of the stack and exiting means popping from the stack. Multitasking is a little harder but really only involves using a list of "windows" instead of a stack, only updating the screen when you know something changes (invalidation), and directing input towards the active "window" (or sometimes switching the active "window" or directing the input to a inactive window, like scroll wheel). Though I digress, lol.

RehabMan · October 21, 2017

Entirely possible that it's broken because of that, I'm not exactly sure why it was even necessary to provide such detailed kext injection disabling... Who's injecting that many kexts? I have FakeSMC and that's it... I install the rest I want after the OS. I think they don't understand that the injection is meant to be used in situations where you can't install kexts... But eh. As for trying to figure out anything with the GUI, good luck with that. There's so many random loops inside of each other because the GUI (rEFIt) was badly designed from the start (sorry Christoph!)... Granted I think Clover has pushed it beyond the breaking point. But GUIs should have only one loop that draws, handles input and dispatches it accordingly.. A single task GUI can be easily implemented with a stack of "screens" that are drawn so the loop just walks down the stack until it reaches a fullscreen "screen" then walks back up the stack drawing each "screen". Entering a menu just pushes that menu onto the top of the stack and exiting means popping from the stack. Multitasking is a little harder but really only involves using a list of "windows" instead of a stack, only updating the screen when you know something changes (invalidation), and directing input towards the active "window" (or sometimes switching the active "window" or directing the input to a inactive window, like scroll wheel). Though I digress, lol.

Agree 100% on the questionable need for this kext management feature.

And also 100% on injection vs. installing... I usually explain to people several times per day that they should be installing kexts, not injecting and that injection is only for essential kexts needed by the installer or recovery.

But I'll work out the issue of InjectKexts=Detect, it is just a matter of time.

And now I have the Esc key and space key working correctly.

And yes, the menu handling code in there could use a redesign (like you mention), but it is workable if you're careful. As always, rushed code is buggy code.

RehabMan · October 21, 2017

But I'll work out the issue of InjectKexts=Detect, it is just a matter of time.

Got it.

I think I was running the wrong build when initially testing (then got sidetracked on the other things I mentioned).

That said, now that InjectKexts=Detect is working again, things are little strange with that kext management menu.

For example, with Detect and FakeSMC.kext installed, you would expect that all the kexts would be marked for exclusion when you enter that menu, but that is not the case... they are unchecked in that scenario which might lead one to believe they'll be injected, which is not going to happen. This is probably what prompted the other changes that broke InjectKexts. But we can't break InjectKexts=Detect for this GUI feature.

So, two things need to happen:

- the initial checkmarks should represent the current state of whether the system will inject or not (depending on InjectKexts setting and FakeSMC status)

- once changes are made to the status of those checkmarks, it should be honored regardless of InjectKexts setting

I'll see if I can work that out (probably won't be today, and all this is happening in my github fork anyway).

Edit: The trick will be how to determine the status of FakeSMC relative to the prelinked kernel when the prelinked kernel hasn't been loaded yet!

Slice · October 22, 2017

I need kexts injection from EFI for a testing purpose. If the testing kexts leads to panic then I can disable it through GUI.

Moreover I can remove it by Shell or place good one instead of it. For example PS2Keyboard. I need the working kext and can't boot with bad one.

About "Detect". What if FakeSMC presents in both places, in SLE and in Other/ ? I think it will work.

RehabMan · October 22, 2017

I need kexts injection from EFI for a testing purpose. If the testing kexts leads to panic then I can disable it through GUI.

Moreover I can remove it by Shell or place good one instead of it. For example PS2Keyboard. I need the working kext and can't boot with bad one.

And I think this gets to the real purpose of this feature.

It really isn't a "kext management" feature at all. It is purely an "injected kext disabler" feature.

And I think it's going to stay that way.

So, for the case that kexts weren't going to be injected anyway, fiddling in this menu will have no effect. And I think that's fine.

But what we really need is a way to force kext injection when it is disabled (eg. due to InjectKexts=No, or InjectKexts=Detect+FakeSMC.kext in cache).

Or to force kext injection off when it is enabled (due to InjectKexts=Yes, or InjectKexts=Detect + FakeSMC.kext NOT in cache).

We used to have these options, but they were removed. I will add them back (to the spacebar menu).

About "Detect". What if FakeSMC presents in both places, in SLE and in Other/ ? I think it will work.

That is the normal configuration.

InjectKexts=Detect

FakeSMC.kext installed to /L/E (or /S/L/E, if you want)

FakeSMC.kext at EFI/Clover/kexts/Other

When you boot recovery or an installer, Clover detects no FakeSMC in cache, so injects the kexts from Clover/kexts.

When you boot your system partition, Clover detects FakeSMC in cache, and ignores all kexts in Clover/kexts.

It is the perfect setup as you get to install kexts where you can, but still have kext injection when you need it.

tluck · October 22, 2017

That is the normal configuration.

InjectKexts=Detect

FakeSMC.kext installed to /L/E (or /S/L/E, if you want)

FakeSMC.kext at EFI/Clover/kexts/Other

When you boot recovery or an installer, Clover detects no FakeSMC in cache, so injects the kexts from Clover/kexts.

When you boot your system partition, Clover detects FakeSMC in cache, and ignores all kexts in Clover/kexts.

It is the perfect setup as you get to install kexts where you can, but still have kext injection when you need it.

Agree. for me, this has been the ideal mechanism for a long time. sorry to jump in here, but i am casting a vote to preserve this model.

Sherlocks · October 22, 2017

@Slice
i arranged source. why suddenly shown "The metadata for this repository is missing. To fix, please try a refresh."
i committed "cleanup kernelAndKextPatches options" like before. can browse commits but strange.
just sf issue?

EDIT1.
build also is no problem.

EDIT2.
Sf is back.

bronxteck · October 23, 2017

so if you have all kexts in some OS/library/extensions how do you boot recovery if you do not use other? that would mean you need kexts in 2 places anyway no? why use LE at all unless there are apple audio kext or some other kext that has SLE dependence you do not need that in recovery or because it take a few milliseconds longer to inject it? or maybe optifix issue with a minority of certain boards?

my point is why are people not supposed to use clovers inject feature and get slapped on the wrist if they say they do. makes no sense.

WinstonAce · October 23, 2017

They have enough kexts (mainly fakesmc) in clover folder to load recovery/install.

In this case, clover will inject the kext because it's not in kextcache.

If loading all kext from clover working for you, I wouldn't bother using /Library/Extensions.

I don't and everything is working fine.

Sent from my ONEPLUS A5000 using Tapatalk

Slice · October 23, 2017

That is the normal configuration.

InjectKexts=Detect

FakeSMC.kext installed to /L/E (or /S/L/E, if you want)

FakeSMC.kext at EFI/Clover/kexts/Other

When you boot recovery or an installer, Clover detects no FakeSMC in cache, so injects the kexts from Clover/kexts.

When you boot your system partition, Clover detects FakeSMC in cache, and ignores all kexts in Clover/kexts.

It is the perfect setup as you get to install kexts where you can, but still have kext injection when you need it.

Anyway. Why not inject FakeSMC from Other even if it presents in kernelcache? Is it dangerous conflict?

Or just for perfect looking?

Recovery also needs LAN kext and Keyboard kext if PS2 for example.

"Detect" mode is not working? I was not going to exclude it. Will look carefully.

    Prop = GetProperty (DictPointer, "InjectKexts");
    if (Prop != NULL) {
      if (Prop->type == kTagTypeTrue) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else if ((Prop->type == kTagTypeString) &&
                 (AsciiStriCmp (Prop->string, "Yes") == 0)) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else if ((Prop->type == kTagTypeString) &&
                 (AsciiStriCmp (Prop->string, "Detect") == 0)) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_CHECKFAKESMC);
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else {
        DBG ("** Warning: unknown custom entry InjectKexts value '%a'\n", Prop->string);
      }

Hey Sherlocks,

if you removed one field from Settings structure then you have to add padding the same size

--- a/rEFIt_UEFI/Platform/Platform.h
+++ b/rEFIt_UEFI/Platform/Platform.h
@@ -1089,7 +1089,6 @@
   UINT64                  DoubleClickTime;
   BOOLEAN                 PointerMirror;
 
-  BOOLEAN                 KernelXCPMAllowed;
   UINT8                   pad7[1];
   UINT8                   CustomBoot;
   EG_IMAGE                *CustomLogo;

So pad7[1] will be pad7[2]

EDITED.

Moreover it should be pad7[6] because of 8 byte alignment

Sherlocks · October 23, 2017

Anyway. Why not inject FakeSMC from Other even if it presents in kernelcache? Is it dangerous conflict?

Or just for perfect looking?

Recovery also needs LAN kext and Keyboard kext if PS2 for example.

"Detect" mode is not working? I was not going to exclude it. Will look carefully.
    Prop = GetProperty (DictPointer, "InjectKexts");
    if (Prop != NULL) {
      if (Prop->type == kTagTypeTrue) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else if ((Prop->type == kTagTypeString) &&
                 (AsciiStriCmp (Prop->string, "Yes") == 0)) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else if ((Prop->type == kTagTypeString) &&
                 (AsciiStriCmp (Prop->string, "Detect") == 0)) {
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_CHECKFAKESMC);
        Entry->Flags = OSFLAG_SET(Entry->Flags, OSFLAG_WITHKEXTS);
      } else {
        DBG ("** Warning: unknown custom entry InjectKexts value '%a'\n", Prop->string);
      }
Hey Sherlocks,
if you removed one field from Settings structure then you have to add padding the same size
--- a/rEFIt_UEFI/Platform/Platform.h
+++ b/rEFIt_UEFI/Platform/Platform.h
@@ -1089,7 +1089,6 @@
   UINT64                  DoubleClickTime;
   BOOLEAN                 PointerMirror;
 
-  BOOLEAN                 KernelXCPMAllowed;
   UINT8                   pad7[1];
   UINT8                   CustomBoot;
   EG_IMAGE                *CustomLogo;
So pad7[1] will be pad7[2]

EDITED.

Moreover it should be pad7[6] because of 8 byte alignment

Okay i will. Thanks

나의 LG-F800S 의 Tapatalk에서 보냄

apianti · October 23, 2017

so if you have all kexts in some OS/library/extensions how do you boot recovery if you do not use other? that would mean you need kexts in 2 places anyway no? why use LE at all unless there are apple audio kext or some other kext that has SLE dependence you do not need that in recovery or because it take a few milliseconds longer to inject it? or maybe optifix issue with a minority of certain boards?

my point is why are people not supposed to use clovers inject feature and get slapped on the wrist if they say they do. makes no sense.

Because injecting kexts uses way more memory than just having the kexts in the kernel cache already. It increases your chances of having problems booting, especially allocation errors, and some kexts cannot work at all when injected. No one cares what you do with your kexts, certainly no one is "slapping you on the wrist." You obviously must use it in certain situations, that's what it's there for, but I see users trying to inject ten kexts and wonder why they can't boot....

They have enough kexts (mainly fakesmc) in clover folder to load recovery/install.

In this case, clover will inject the kext because it's not in kextcache.

If loading all kext from clover working for you, I wouldn't bother using /Library/Extensions.

I don't and everything is working fine.

Sent from my ONEPLUS A5000 using Tapatalk

Yes, the mechanism that slice removed is how the recovery was easily booted. Also, bad advice. You should not be using injection as an installation method. Install the kexts. Period. You shouldn't be trying to justify injecting kexts, you wouldn't advice someone not install a driver in windows would you? No - because that's ridiculous, just like it is in macOS. Also it doesn't matter where you install them, just be aware that kexts are restricted if you don't disable the SIP restriction(s).

WinstonAce · October 23, 2017

Well, that's your opinion.

Using this method for many years now without problems.

And no, it isn't windows so the comparison is wrong.

BTW, kext from EFI will load with SIP enabled.

Sent from my ONEPLUS A5000 using Tapatalk

RehabMan · October 23, 2017

Anyway. Why not inject FakeSMC from Other even if it presents in kernelcache? Is it dangerous conflict?

Unnecessary risk/memory usage/etc.

If FakeSMC.kext is already installed, no need to inject.

Kind of a "don't fix what is not broken" sort of thing.

Also, I haven't tested to see what happens if you have conflicting versions between the two (which one wins?).

Recovery also needs LAN kext and Keyboard kext if PS2 for example.

Yes, of course.

Essential kexts would be placed in kexts/Other along with FakeSMC.kext.

"Detect" mode is not working? I was not going to exclude it. Will look carefully.

It is working now with your r4242 commit reverted.

So pad7[1] will be pad7[2]

padding to align struct members at the appropriate offset is something the compiler is quite capable of doing by itself.

Slice · October 23, 2017

It is working now with your r4242 commit reverted.

OK, I just don't remember why I did this. May be because of other bug.

padding to align struct members at the appropriate offset is something the compiler is quite capable of doing by itself.

No, the problem is deeper.

The structure is packed and so all reading should be with ReadUnaligned method, it's painful.

So I keep all field as natural aligned. It is also affected clover-genconfig.

If rewrite Clover from initial there will be other way but I just keeping this way.

RehabMan · October 23, 2017

No, the problem is deeper.

The structure is packed and so all reading should be with ReadUnaligned method, it's painful.

Easy to move that struct (and perhaps others) outside of the #pragma pack(1).

Clover Problems and Solutions

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