vit9696 Posted December 10, 2017 Share Posted December 10, 2017 Zenith432, hi, could you please reread carefully what I wrote if you are willing to resolve the issue? I think you missed the point =) These strings are added by boot.efi, and they are not relevant to the nature of the bug. The issue is that Clover is not injecting com.apple.driver.KextExcludeList, when it unconditionally should be by XNU design. Link to comment Share on other sites More sharing options...
truemac Posted December 10, 2017 Share Posted December 10, 2017 These strings are not found in Clover. Link to comment Share on other sites More sharing options...
Slice Posted December 10, 2017 Share Posted December 10, 2017 This messages known from 10.5 09/12/17 19:14:54,000 kernel[0]: "name" not a kext 09/12/17 19:14:54,000 kernel[0]: "FailedCLUT" not a kext 09/12/17 19:14:54,000 kernel[0]: "FailedImage" not a kext and never was an obstacle for OSX. They are related to Clover because it injected kexts not officail way. 4 Link to comment Share on other sites More sharing options...
Zenith432 Posted December 10, 2017 Share Posted December 10, 2017 How about "resolve by ignoring these messages" like all the other messages in console log that seem like they may be a problem but don't cause any harm. Or find a kernel patch to make OSKext::createExcludeListFromBooterData stop looking for KextExcludeList in /chosen/memory-map. Link to comment Share on other sites More sharing options...
oSxFr33k Posted December 10, 2017 Share Posted December 10, 2017 Your config is wrong for wifi. 나의 LG-F800S 의 Tapatalk에서 보냄 Just realized in Kernel and Kext Patches my bundle name for the WiFi kext was wrong, "AirPortBrcm4360" instead of "com.apple.driver.AirPort.Brcm4360". Why it worked fine in v42xx versions versus 43xx versions is beyond me. 1 Link to comment Share on other sites More sharing options...
WinstonAce Posted December 10, 2017 Share Posted December 10, 2017 It changed in commit 4305 https://sourceforge.net/p/cloverefiboot/code/4305/ Link to comment Share on other sites More sharing options...
Sherlocks Posted December 10, 2017 Share Posted December 10, 2017 Ok I will try to tell Rehabman this ID. Moreover I want to know if Clover support vertical screen such as 1536x2048. Because I want to set Clover screen to 768x1024 but Clover can’t recognize this.Clover can only recognize 1024x768 but 768x1024 can’t. So I want To know if Clover have this restrict about resolution set. Thanks. 从我的 iPhone 发送,使用 Tapatalk did you patched dvmt 64mb over? EDIT1. i'm suspecting your system 4gb ram no patched dvmt 64 over. your system has 32mb is it right? also if you use 16160000, gpu vram size will show 1024mb, is it right? EDIT2. upload screenshot about your gpu info after click "about mac" on left top Link to comment Share on other sites More sharing options...
Pavo Posted December 10, 2017 Share Posted December 10, 2017 Anyone have a working SSDT method to inject Skylake LPC so that AppleLPC.kext will load? I have this: /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20171110 (64-bit version)(RM) * Copyright (c) 2000 - 2017 Intel Corporation * * Disassembling to non-symbolic legacy ASL operators * * Disassembly of iASL0Z6ufm.aml, Sun Dec 10 16:06:08 2017 * * Original Table Header: * Signature "SSDT" * Length 0x000000B7 (183) * Revision 0x01 * Checksum 0xE9 * OEM ID "mfc88" * OEM Table ID "LPCB" * OEM Revision 0x00000000 (0) * Compiler ID "INTL" * Compiler Version 0x20171110 (538382608) */ DefinitionBlock ("", "SSDT", 1, "mfc88", "LPCB", 0x00000000) { External (_SB_.PCI0.LPCB, DeviceObj) // (from opcode) Method (_SB.PCI0.LPCB._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x06) { "device-id", Buffer (0x17) { "0xC1, 0x9C, 0x00, 0x00" }, "compatible", Buffer (0x0D) { "pci8086,9cc1" }, "name", Buffer (0x0D) { "pci8086,9cc1" } }) } } But its not working. Link to comment Share on other sites More sharing options...
vit9696 Posted December 10, 2017 Share Posted December 10, 2017 How about "resolve by ignoring these messages" like all the other messages in console log that seem like they may be a problem but don't cause any harm. Or find a kernel patch to make OSKext::createExcludeListFromBooterData stop looking for KextExcludeList in /chosen/memory-map. This messages known from 10.5 09/12/17 19:14:54,000 kernel[0]: "name" not a kext 09/12/17 19:14:54,000 kernel[0]: "FailedCLUT" not a kext 09/12/17 19:14:54,000 kernel[0]: "FailedImage" not a kext and never was an obstacle for OSX. They are related to Clover because it injected kexts not officail way. To be completely honest stuff like that does not bother me either, but since I explored the issue and found an obvious (though surely low-pri/cosmetic) bug I feel responsible to report. Patching OSKext::createExcludeListFromBooterData (in fact the whole call could be replaced with a ret) is of course an option, but is more like "make the messages disappear" way rather than implement the functionality XNU expects. In either case, if anybody wants to write a fix, he at least is now aware what is wrong. 8 Link to comment Share on other sites More sharing options...
oSxFr33k Posted December 10, 2017 Share Posted December 10, 2017 It changed in commit 4305 https://sourceforge.net/p/cloverefiboot/code/4305/ Link broken Link to comment Share on other sites More sharing options...
gujiangjiang Posted December 11, 2017 Share Posted December 11, 2017 did you patched dvmt 64mb over? EDIT1. i'm suspecting your system 4gb ram no patched dvmt 64 over. your system has 32mb is it right? also if you use 16160000, gpu vram size will show 1024mb, is it right? EDIT2. upload screenshot about your gpu info after click "about mac" on left top Yes 1024M with 161e0000 but 1536M with 16260006. I just want to know Clover GUI screen resolution change. 从我的 iPhone 发送,使用 Tapatalk Link to comment Share on other sites More sharing options...
Sherlocks Posted December 11, 2017 Share Posted December 11, 2017 Yes 1024M with 161e0000 but 1536M with 16260006. I just want to know Clover GUI screen resolution change. 从我的 iPhone 发送,使用 Tapatalk I will back 0x16260006. You have to manually add 161e0000. 161e0000 default 1024. Most of broadwell models has 1536MB VRAM. Also its benefits more than 1024MB. 16260006 was proved by many user. I'm researched frambuffer more yesterday with website. It does not matter. We provide manual value that user want. Clover just support best value to use macOS and boot without fail 나의 LG-F800S 의 Tapatalk에서 보냄 Anyone have a working SSDT method to inject Skylake LPC so that AppleLPC.kext will load? I have this: /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20171110 (64-bit version)(RM) * Copyright (c) 2000 - 2017 Intel Corporation * * Disassembling to non-symbolic legacy ASL operators * * Disassembly of iASL0Z6ufm.aml, Sun Dec 10 16:06:08 2017 * * Original Table Header: * Signature "SSDT" * Length 0x000000B7 (183) * Revision 0x01 * Checksum 0xE9 * OEM ID "mfc88" * OEM Table ID "LPCB" * OEM Revision 0x00000000 (0) * Compiler ID "INTL" * Compiler Version 0x20171110 (538382608) */DefinitionBlock ("", "SSDT", 1, "mfc88", "LPCB", 0x00000000){ External (_SB_.PCI0.LPCB, DeviceObj) // (from opcode) Method (_SB.PCI0.LPCB._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x06) { "device-id", Buffer (0x17) { "0xC1, 0x9C, 0x00, 0x00" }, "compatible", Buffer (0x0D) { "pci8086,9cc1" }, "name", Buffer (0x0D) { "pci8086,9cc1" } }) }}But its not working. no need AppleLPC loaded on skylake+. I checked it. I just added EFICheckDisabler.kext to disable eficheck. 9cc1 is broadwell lpc id. 나의 LG-F800S 의 Tapatalk에서 보냄 3 Link to comment Share on other sites More sharing options...
gujiangjiang Posted December 11, 2017 Share Posted December 11, 2017 I will back 0x16260006. You have to manually add 161e0000. 161e0000 default 1024. Most of broadwell models has 1536MB VRAM. Also its benefits more than 1024MB. 16260006 was proved by many user. I'm researched frambuffer more yesterday with website. It does not matter. We provide manual value that user want. Clover just support best value to use macOS and boot without fail 나의 LG-F800S 의 Tapatalk에서 보냄 no need AppleLPC loaded on skylake+. I checked it. I just added EFICheckDisabler.kext to disable eficheck. 9cc1 is broadwell lpc id. 나의 LG-F800S 의 Tapatalk에서 보냄 OK,Very thanks to your help. 从我的 iPhone 发送,使用 Tapatalk Link to comment Share on other sites More sharing options...
Zenith432 Posted December 11, 2017 Share Posted December 11, 2017 You keep repeating the word "expect" without stating in your analysis what OSKext::createExcludeListFromBooterData does if it doesn't find one. If it works without one, this is a feature request, not a bug - one which isn't a high priority because there's another mechanism to get the kernel to accept unsigned kexts which is to disable SIP. You don't state in your analysis whether the 2nd KextExcludeList has to be digitally signed by Apple like the one in /S/L/E (when SIP is enabled of course...). If it does, there's nothing that can be injected other than the same one as in /S/L/E - which makes it a useless feature. There's nothing preventing a user from putting a KextExcludeList in \EFI\CLOVER\kexts\Other today. It is not Clover's fault that one component written by Apple (OSKext) is issuing frivolous error messages about data inserted by another component written by Apple (boot.efi). To be completely honest stuff like that does not bother me either, but since I explored the issue and found an obvious (though surely low-pri/cosmetic) bug I feel responsible to report. Patching OSKext::createExcludeListFromBooterData (in fact the whole call could be replaced with a ret) is of course an option, but is more like "make the messages disappear" way rather than implement the functionality XNU expects. In either case, if anybody wants to write a fix, he at least is now aware what is wrong. Link to comment Share on other sites More sharing options...
nms Posted December 11, 2017 Share Posted December 11, 2017 You keep repeating the word "expect" without stating in your analysis what OSKext::createExcludeListFromBooterData does if it doesn't find one. If it works without one, this is a feature request, not a bug - one which isn't a high priority because there's another mechanism to get the kernel to accept unsigned kexts which is to disable SIP. You don't state in your analysis whether the 2nd KextExcludeList has to be digitally signed by Apple like the one in /S/L/E (when SIP is enabled of course...). If it does, there's nothing that can be injected other than the same one as in /S/L/E - which makes it a useless feature. There's nothing preventing a user from putting a KextExcludeList in \EFI\CLOVER\kexts\Other today. It is not Clover's fault that one component written by Apple (OSKext) is issuing frivolous error messages about data inserted by another component written by Apple (boot.efi). As for #4, is not it a kind of MITM (man in the middle) attack? Clover modifies "expected" order? Link to comment Share on other sites More sharing options...
Slice Posted December 11, 2017 Share Posted December 11, 2017 As for #4, is not it a kind of MITM (man in the middle) attack? Clover modifies "expected" order? Yes, Clover injected kexts from /EFI/CLOVER/kexts/Other not expected by Apple. Link to comment Share on other sites More sharing options...
nms Posted December 11, 2017 Share Posted December 11, 2017 Yes, Clover injected kexts from /EFI/CLOVER/kexts/Other not expected by Apple. As I understand, the problem (unexpected feature?) not in injection itself, but in the order of injection. Link to comment Share on other sites More sharing options...
Slice Posted December 11, 2017 Share Posted December 11, 2017 As I understand, the problem (unexpected feature?) not in injection itself, but in the order of injection. What is "injection itself"? Kexts from Clover folder appears before kernelcache, it is order of injection. Link to comment Share on other sites More sharing options...
Zenith432 Posted December 11, 2017 Share Posted December 11, 2017 (edited) This is what memory-map looks like in VMware guest. No Clover involvement. The words "FailedCLUT" or "FailedImage" do not appear in a grep of 'log show'. I don't know that the five injected drivers are or if they contain a KextExcludeList. PS: SIP is disabled. Update: Same result with SIP enabled, so whatever VMware does, these messages are not emitted in the kernel log. Edited December 11, 2017 by Zenith432 Link to comment Share on other sites More sharing options...
mhaeuser Posted December 11, 2017 Share Posted December 11, 2017 This is what memory-map looks like in VMware guest. No Clover involvement. The words "FailedCLUT" or "FailedImage" do not appear in a grep of 'log show'. I don't know that the five injected drivers are or if they contain a KextExcludeList. PS: SIP is disabled. VMWare does not inject "booter kexts". Link to comment Share on other sites More sharing options...
Zenith432 Posted December 11, 2017 Share Posted December 11, 2017 What are those "Driver-"s? Something different from booter kexts? VMWare does not inject "booter kexts". Link to comment Share on other sites More sharing options...
mhaeuser Posted December 11, 2017 Share Posted December 11, 2017 What are those "Driver-"s? Something different from booter kexts?Sorry, pic didn't load on my phone ;pOdd, I was 100% sure VMWare injected to prelinkedkernel directly for a while. Which ver was used? Link to comment Share on other sites More sharing options...
vit9696 Posted December 11, 2017 Share Posted December 11, 2017 Sigh, in this case I will have to explain some XNU internals. 1. You keep repeating the word "expect" without stating in your analysis what OSKext::createExcludeListFromBooterData does if it doesn't find one. If it works without one, this is a feature request, not a bug - one which isn't a high priority because there's another mechanism to get the kernel to accept unsigned kexts which is to disable SIP. 2. You don't state in your analysis whether the 2nd KextExcludeList has to be digitally signed by Apple like the one in /S/L/E (when SIP is enabled of course...). If it does, there's nothing that can be injected other than the same one as in /S/L/E - which makes it a useless feature. 3. There's nothing preventing a user from putting a KextExcludeList in \EFI\CLOVER\kexts\Other today. 4. It is not Clover's fault that one component written by Apple (OSKext) is issuing frivolous error messages about data inserted by another component written by Apple (boot.efi). 1. It is not like XNU source code is closed, you could have just opened libkern/c++/OSKext.cpp. To save your time I could repeat that currently(!) it only warns about extra variables not starting with a correct prefix (not being kexts). 2. There is no signature concept for all booter kexts in the first place, so the words digitally signed are meaningless in XNU context. This is obvious, if you realise that you need a trusted storage for kext signature verification, which unlike iOS you do not have on macOS. Another thing is that KextExclude list is obviously replaced from prelinked one if it exists there, and the exclusion list in booter kexts is only relevant for booter kexts. I consider this to be the way Apple expects one to enable/disable booter-injected extensions (I suppose instead of what Clover does now). 3. There actually is, I discovered that the current Clover kext injection implementation does not properly inject Info.plists, for some reason OSKextExcludeList will not be present in a kext injected by Clover effectively making XNU to panic. 4. I agree that it is a complicated edge-case question, I'd say the warnings are reasonably strange, since the iteration order should not be guaranteed and the other non-kext keys definitely should be there. Which kind of makes the issue itself radar-worthy. 1 Link to comment Share on other sites More sharing options...
Zenith432 Posted December 11, 2017 Share Posted December 11, 2017 The current one (14) and 10.13.2 in guest. Which ver was used? Link to comment Share on other sites More sharing options...
Pavo Posted December 11, 2017 Share Posted December 11, 2017 Found a interesting workaround to fix the OSInstall.mpkg issue some have been having. Change your date manually. Link to comment Share on other sites More sharing options...
Recommended Posts