Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

joevt
joevt
Posted
Posted (edited)

Here are the full DarwinDumper report and with out BIOS and HTML.

The problem is visible in SMBIOS.txt. Line 40. The Product Name has the correct length, but the last 3 characters of "MacBookPro13,1" are replaced by 3 spaces to give "MacBookPro1 ". SMBIOS.txt does not contain all the bytes of the SMBIOS though (maybe the code that creates the SMBIOS.txt file could be changed to add those bytes?) Those bytes exist in IOReg.txt line 740. You can see what they look like by copying those bytes into a command like this:

echo 001800000102000003ff009a893f01001700830f0001ffff4170706c6520496e632e004d42503133332e38385a2e303232362e4230382e313631313330313730300031312f33302f323031360000011b01000102050444454c4c310010368044b7c04f5237320603064170706c6520496e632e004d6163426f6f6b50726f31202020004d61632d413543363746372020202020202020200043303253435a33444754445900312e30004d6163426f6f6b2050726f000002100200010203040009 | xxd -p -r | xxd
which gives this:

0000000: 0018 0000 0102 0000 03ff 009a 893f 0100  .............?..
0000010: 1700 830f 0001 ffff 4170 706c 6520 496e  ........Apple In
0000020: 632e 004d 4250 3133 332e 3838 5a2e 3032  c..MBP133.88Z.02
0000030: 3236 2e42 3038 2e31 3631 3133 3031 3730  26.B08.161130170
0000040: 3000 3131 2f33 302f 3230 3136 0000 011b  0.11/30/2016....
0000050: 0100 0102 0504 4445 4c4c 3100 1036 8044  ......DELL1..6.D
0000060: b7c0 4f52 3732 0603 0641 7070 6c65 2049  ..OR72...Apple I
0000070: 6e63 2e00 4d61 6342 6f6f 6b50 726f 3120  nc..MacBookPro1 
0000080: 2020 004d 6163 2d41 3543 3637 4637 2020    .Mac-A5C67F7  
0000090: 2020 2020 2020 2000 43** **** **** ****         .C*******
00000a0: **** **59 0031 2e30 004d 6163 426f 6f6b  ***Y.1.0.MacBook
00000b0: 2050 726f 0000 0210 0200 0102 0304 0009   Pro............
where you can see those three spaces after MacBookPro1

 

(You can also see the Serial Number which is purposefully masked in SMBIOS.txt)

 

SMBIOS table type 1 starts at 0x4e. The format is defined in the document "System Management BIOS (SMBIOS) Reference Specification". The bytes for table type 1 are these:

 

01                                          type 1 header
1b                                          length of 2.4 header
0100                                        handle
01 *                                        manufacturer string
02 *                                        product name string
05 *                                        version string
04 *                                        serial number string
44454c4c310010368044b7c04f523732            uuid                  DELL1..6.D..OR72
06                                          wake-up type (6=power switch)
03 *                                        SKU string
06 *                                        family string
4170706c6520496e632e00                     1:          Apple Inc..
4d6163426f6f6b50726f3120202000             2:          MacBookPro1   .
4d61632d4135433637463720202020202020202000 3:          Mac-A5C67F7         .
43********************5900                 4:          C**********Y.
312e3000                                   5:          1.0.
4d6163426f6f6b2050726f00                   6:          MacBook Pro..
00
Note that the SKU string also has characters beyond character 11 replaced by spaces. Otherwise, I don't see anything wrong with these bytes.

 

I'm not sure the info from dmidmp.txt.tar.gz is useful.

Edited by joevt
  • Like 2
Link to comment
Share on other sites
syscl
syscl
Posted
Posted

Well, I've built a new kernel extension FakeSMBIOS to spoof the SMBIOS for macOS during startup. 

 

Here's the source code of FakeSMBIOS https://github.com/syscl/FakeSMBIOS

 

I know there's still long way to go(still some bugs), but by spoofing the SMBIOS, some bugs fixed, one of the example is the Boot Camp Assistant

post-950366-0-74643500-1482348872_thumb.png

 

Wish there will be more testers and better solution :)

 

Here's the prebuilt kext. FakeSMBIOS can be placed Clover to inject..

FakeSMBIOS.kext.zip

 

credit also Voodoo project

 

 

syscl

  • Like 2
Link to comment
Share on other sites
genzai
genzai
Posted
Posted

 

 

 

Wish there will be more testers and better solution :)

 

 

 

syscl

Can you make a new thread for this and link to it here? And then put some more info about this kext and what problems it tries to solve and what kind of testing you would like us to do? If you just post it here it will be lost in this long thread very quickly.

g\

Link to comment
Share on other sites
syscl
syscl
Posted
Posted

Can you make a new thread for this and link to it here? And then put some more info about this kext and what problems it tries to solve and what kind of testing you would like us to do? If you just post it here it will be lost in this long thread very quickly.

g\

Thanks for the tip @genzai,

 

I will later, but there's still some bugs(cannot spoof Model Identifier) thus I need to do some more research about this issue.

 

Thanks,

syscl

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

I think it is impossible to implement this via a kext...

Firstly. Clover patches SMBios at early boot, before boot.efi loading. How can you make a kext load before boot.efi loads?

Secondly. According to your source code. You just send the correct SMBios data to certain services like BootCamp you mentioned. But all kexts that matches board-id will not. Note that your FakeSMBios can not load the earliest. So. Some kexts/frameworks still get the wrong data.

And also. I think all verbs on SMBios after Clover patches SMBios or in other words that after loading boot.efi, will not work cuz may useless...

May think write a efi module to do so? Let it load after Clover patched SMBios. Then you got correct data before boot.efi loaded.

 

But anyway. Thanks for your hard work.

 

PMheart

  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I think it is impossible to implement this via a kext...

Firstly. Clover patches SMBios at early boot, before boot.efi loading. How can you make a kext load before boot.efi loads?

Secondly. According to your source code. You just send the correct SMBios data to certain services like BootCamp you mentioned. But all kexts that matches board-id will not. Note that your FakeSMBios can not load the earliest. So. Some kexts/frameworks still get the wrong data.

And also. I think all verbs on SMBios after Clover patches SMBios or in other words that after loading boot.efi, will not work cuz may useless...

May think write a efi module to do so? Let it load after Clover patched SMBios. Then you got correct data before boot.efi loaded.

 

But anyway. Thanks for your hard work.

 

PMheart

I am not sure if Dell BIOS is not editing SMBIOS after boot.efi.

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

I am not sure if Dell BIOS is not editing SMBIOS after boot.efi.

Just like said above,the length of dim is correct but the last 3 characters replaced by space character.

 

Especially,I found this phenomenon is common in DELL skl laptop including XPS,Insprin,Aw,latitude and more have this bug.the smbios is abnormal and with a lot of bugs such as boocamp can't be opened.so i think this bug will always exist in the future dell laptops and it hope to be fixed.

 

But @syscl had build a kext to change the DMI after boot and you can look into the code to see how it works and found whether it can be done by Clover?

I am not sure if Dell BIOS is not editing SMBIOS after boot.efi.

And if any solution to found the log with smbios injection by clover to see where caused this bug.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

And if any solution to found the log with smbios injection by clover to see where caused this bug.

Uncomment the line

// egSaveFile(NULL, L"EFI\\CLOVER\\misc\\smbios.bin", (UINT8*)(UINTN)SmbiosEpsNew, SmbiosEpsNew->TableLength);

 
at the end of file smbios.c
  • Like 1
Link to comment
Share on other sites
joevt
joevt
Posted
Posted

@Slice

Here you go~

 

attachicon.gifsmbios.bin.zip

 

syscl

This file shows that Clover is putting the values in correctly. You also should give the final value from ioreg to compare.

 

It might be a coincidence that the product name "XPS 13 9350" is exactly 11 characters which is the number of characters that are unchanged when booting Mac OS X.

 

Two questions:

 

1) Is it only Product Name and SKU Number being affected? To test this, make all the strings longer than 11 characters. Including Family, Version, Manufacturer.

 

2) Is it only string index 2 and 3 being affected? To test this, change the Clover code to add 10 dummy unused strings (15 characters each), then add the type 1 strings so that Manufacturer will be string 11, Product Name will be string 12, etc.

 

After making the above changes, compare the SMBIOS file from Clover with the SMBIOS hex from ioreg.

  • Like 2
Link to comment
Share on other sites
joevt
joevt
Posted
Posted

Glad to see it is not Clover bug.

Still need to find out what happens to the smbios between when "InstallConfigurationTable (&gEfiSmbiosTableGuid" in FinalizeSmbios and when boot.efi is called in StartLoader.

 

Maybe add a "EfiGetSystemConfigurationTable (&gEfiVectorHandoffTableGuid" and another "egSaveFile(NULL, L"EFI\\CLOVER\\misc\\smbios.bin" with a different file name to see if it changes later?

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

I think we can add print to screen some strings from smbios at the OnExitBootService()

@Slice, I just added 

SMBIOS_TABLE_ENTRY_POINT		*gBSMBIOS; // get bios smbios table
    EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID*)&gBSMBIOS);
    egSaveFile(NULL, L"EFI\\CLOVER\\misc\\efismbios.bin", (UINT8*)(UINTN)gBSMBIOS, SmbiosEpsNew->TableLength);

at the end of smbios.c and compare smbios.bin and efismbios.bin which are the same. I double my operation is incorrect. 

 

I just find the definition of InstallConfigurationTable(EFI_GUID* Guid, VOID* Table), but cannot find how this function works. I noticed there's InstallConfigurationTable.c, but what I found in that file is this

if (Table != NULL) {
      //
      // If Table is not NULL, then this is a modify operation.
      // Modify the table enty and return.
      //
      ConfigurationTable[Index].VendorTable = Table;
      return EFI_SUCCESS;
}

It just make the ConfigurationTable with the &Guid points to the patched SmbiosEpsNew right? I am not sure, but I want to figure out this issue. Please shine some light on this, thanks.

 

Thanks in advance,

syscl

  • Like 2
Link to comment
Share on other sites
syscl
syscl
Posted
Posted

This function just write the pointer to SMBIOS table into System Table. That's all.

@Slice, thanks for the clarification. So, we can later on repatched the SMBIOSStructureType1 buffer to correct this bug? Or can we create a new buffer with the protected property for the product name in SMBIOS_TABLE_TYPE1?

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

@Slice, 

 

I added this piece of code at the OnExitBootService()

SMBIOS_TABLE_ENTRY_POINT		*gBSMBIOS; // get bios smbios table
EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID*)&gBSMBIOS);
egSaveFile(NULL, L"EFI\\CLOVER\\misc\\exitsmbios.bin", (UINT8*)(UINTN)gBSMBIOS, gBSMBIOS->TableLength);

And exitsmbios.bin is the same as smbios.bin, name is correct. Thus I added print in DataHubCpu.c 

if (!EFI_ERROR(Status)) {
    ProductName         = AllocateZeroPool(64);
    AsciiStrToUnicodeStr(gSettings.ProductName, ProductName);
      DBG("DataHubCpu: ProductName: %a\n", gSettings.ProductName);
...
 LogDataHub(&gEfiMiscSubClassGuid,      L"Model",                ProductName,         (UINT32)StrSize(ProductName));
      DBG("DataHubCpu: ProductName from efi misc: %s\n", ProductName);
...

Still correct productName. Here's the boot.log and smbios.bin

bootlog_and_smbios.zip

 

So, OnBootExitService() and DataHubDxe indicates during Clover's progress, SMBIOSStructureType1 table hasn't been touched. I double the issue is when macOS access the SMBIOSStructureType1 table then trigger some firmware's limitation or bugs. Is it possible to emulate SMBIOS as legacy Clover? Or as I said, once OnBootExitService() return, allocate a new buffer and remap SMBIOS Table Type1 to bypass the problem SMBIOS?

 

Wait for your reply,

syscl

 

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

Maybe possible GUI bug booting with HDMI.

If I boot Clover normally, gui is offcentred/weird,

If I boot Clover using F11 boot menu, GUI is shown correctly

WTF!

Legacy vs UEFI boot?

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