Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

vit9696
vit9696
Posted
Posted

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
Slice
Slice
Posted
Posted

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.

  • Like 4
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

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
oSxFr33k
oSxFr33k
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

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
Pavo
Pavo
Posted
Posted

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.

 

mk1lJ23.png

Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted

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.
  • Like 8
Link to comment
Share on other sites
gujiangjiang
gujiangjiang
Posted
Posted

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
Sherlocks
Sherlocks
Posted
Posted

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.

 

mk1lJ23.png

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에서 보냄

  • Like 3
Link to comment
Share on other sites
gujiangjiang
gujiangjiang
Posted
Posted

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
Zenith432
Zenith432
Posted
Posted
  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).

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
nms
nms
Posted
Posted

 

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

 

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
Slice
Slice
Posted
Posted

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
Slice
Slice
Posted
Posted

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
Zenith432
Zenith432
Posted
Posted (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.

post-446538-0-39953300-1512990084_thumb.jpeg

Edited by Zenith432
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

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
vit9696
vit9696
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...