- Joined
- Aug 26, 2015
- Messages
- 4
- Motherboard
- HUANAN X79 V2.46 C602 Chipset
- CPU
- E5-2670 V1 C2
- Graphics
- GTX 1050Ti
- Mac
- Mobile Phone
Hi guys,
My computer hardware is my signature.
Currently, 10.12.6 is perfect and my EFI is here.
Problem Description:
When I tried to boot 10.13 DP5, I encountered AppleACPIPlatform problem: https://www.dropbox.com/s/izzhtildypf0ur1/IMG_1912.JPG?dl=0
Typical Causes and Solutions:
After searching google for couple of days and with the help of PMheart I found Alext James's article : http://alextjam.es/d...leacpiplatform/
Because signed char become negative when bigger than 0x7f, Apple rewrote isprint method but seems to forget to cast char to unsigned. Thus, if OemId, Signature、OemId、OemTableId or AslCompilerId in any ACPI table contains a char greater than 0x7f, it will cause a memory overflow.
Most people can solve by:
I took a video of my boot process using -verbose, debug=0x100, keepsyms=1 :
see here : https://www.dropbox....b/boot.mp4?dl=0
In the trace, the boot process stuck at isspace other than isprint.
Out to curiosity, I decompiled AppleACPIPlatform and saw isspace looks like this:
And in C language it looks like this:
It uses __ctype as an array and rdi, which acts as argument in assembly language, as a pointer to find some char and put it into al.
I checked the length of __ctype is 256, thus any normal byte, which is 16 bits, won't cause overflow.
However, Apple didn't cast arg0 to unsigned char. Thus, any char that's greater than 0x7f will also cause an overflow.
Follw the trace, I found _AcpiUtStrtoul64 the source code is here. Looks like it just uses a loop to judge whether it's a space. No other useful information were found during further dig.
New Discovery and Dilemma
Occasionally, i decompiled two programs written to test signed and unsigned char, and were surprised to find,
the only difference between 'cast to unsigned' and 'stay signed' in assembly language is that when delivering argument, unsigned used 'movzx' and singed used 'movsx'.
In assembly language, arguments are delivered by register rdi. So, I think, if I change 'movsx' to 'movzx' then this problem can be solved. Here's where isspace is called inside _AcpiUtStrtoul64:
Note that edi is the lower 32 bit of rdi .
However, after patching in Clover, it sticks that line 0000000000001178 . And checking the register printed, register edi is empty. That means something's wrong when executing movzx .
If I do not change movsx to movzx, at the panic scene we can see in the above video that register rdi is 0x00000000 ffffffa4 , thus edi is 0xffff ffa4 .
Obviously, the char that caused the problem should be A4. However, I searched APIC but didn't find A4. There is a A4 in DSDT but I have no idea how to modify.
BIOS rom, all of my ACPI tables and modified DSDT/SSDT can be found in attachment.
Need Someone's Help
So, here I'm at a very embarrassed stage don't know where's wrong even what to do next... Maybe something's wrong with one of my ACPI tables? Or with AppleACPIPlatform? Or with AppleSMCRTC?
I'm pretty sure I'm not alone with this question, someone willing to dig into it please check my raw ACPI tables, BIOS ROM, modified DSDT/SSDT and my current EFI folder. Thanks very much.
My computer hardware is my signature.
Currently, 10.12.6 is perfect and my EFI is here.
Problem Description:
When I tried to boot 10.13 DP5, I encountered AppleACPIPlatform problem: https://www.dropbox.com/s/izzhtildypf0ur1/IMG_1912.JPG?dl=0
Typical Causes and Solutions:
After searching google for couple of days and with the help of PMheart I found Alext James's article : http://alextjam.es/d...leacpiplatform/
Because signed char become negative when bigger than 0x7f, Apple rewrote isprint method but seems to forget to cast char to unsigned. Thus, if OemId, Signature、OemId、OemTableId or AslCompilerId in any ACPI table contains a char greater than 0x7f, it will cause a memory overflow.
Most people can solve by:
- dropping MATS/BGRT table( or other table )
- add FixHeaders_20000000 in clover ACPI patch
- Modify MATS/BGRT/other table and change that char to lower than 0x80
- I dropped all of my ACPI tables except DSDT and APIC, cuz I cannot boot without these two
- I searched for APIC and DSDT, none of their OemId, Signature、OemId、OemTableId or AslCompilerId contains char greater than 0x7f
I took a video of my boot process using -verbose, debug=0x100, keepsyms=1 :
see here : https://www.dropbox....b/boot.mp4?dl=0
In the trace, the boot process stuck at isspace other than isprint.
Out to curiosity, I decompiled AppleACPIPlatform and saw isspace looks like this:
Code:
_isspace:
000000000001f5cf push rbp ; CODE XREF=_AcpiUtStrtoul64+71, _AcpiUtStrtoul64+89
000000000001f5d0 mov rbp, rsp
000000000001f5d3 lea rax, qword [__ctype]
000000000001f5da mov al, byte [rdi+rax]
000000000001f5dd and al, 0x20
000000000001f5df shr al, 0x5
000000000001f5e2 pop rbp
000000000001f5e3 ret
Code:
int _isspace(int arg0) {
rax = (int)__ctype[arg0];
return (rax & 0x20) >> 5;
}
I checked the length of __ctype is 256, thus any normal byte, which is 16 bits, won't cause overflow.
However, Apple didn't cast arg0 to unsigned char. Thus, any char that's greater than 0x7f will also cause an overflow.
Follw the trace, I found _AcpiUtStrtoul64 the source code is here. Looks like it just uses a loop to judge whether it's a space. No other useful information were found during further dig.
New Discovery and Dilemma
Occasionally, i decompiled two programs written to test signed and unsigned char, and were surprised to find,
the only difference between 'cast to unsigned' and 'stay signed' in assembly language is that when delivering argument, unsigned used 'movzx' and singed used 'movsx'.
In assembly language, arguments are delivered by register rdi. So, I think, if I change 'movsx' to 'movzx' then this problem can be solved. Here's where isspace is called inside _AcpiUtStrtoul64:
Code:
0000000000001153 mov qword [r14], 0x0
000000000000115a movsx edi, byte [r15]
000000000000115e test edi, edi
0000000000001160 je loc_12b5
0000000000001166 mov dword [rbp+var_2C], esi
0000000000001169 xor eax, eax
000000000000116b call _isspace
0000000000001170 lea rbx, qword [r15+1]
0000000000001174 test eax, eax
0000000000001176 je loc_118d
loc_1178:
0000000000001178 movsx edi, byte [rbx] ; argument #1 for method _isspace, CODE XREF=_AcpiUtStrtoul64+99
000000000000117b xor eax, eax
000000000000117d call _isspace
0000000000001182 inc rbx
0000000000001185 test eax, eax
However, after patching in Clover, it sticks that line 0000000000001178 . And checking the register printed, register edi is empty. That means something's wrong when executing movzx .
If I do not change movsx to movzx, at the panic scene we can see in the above video that register rdi is 0x00000000 ffffffa4 , thus edi is 0xffff ffa4 .
Obviously, the char that caused the problem should be A4. However, I searched APIC but didn't find A4. There is a A4 in DSDT but I have no idea how to modify.
BIOS rom, all of my ACPI tables and modified DSDT/SSDT can be found in attachment.
Need Someone's Help
So, here I'm at a very embarrassed stage don't know where's wrong even what to do next... Maybe something's wrong with one of my ACPI tables? Or with AppleACPIPlatform? Or with AppleSMCRTC?
I'm pretty sure I'm not alone with this question, someone willing to dig into it please check my raw ACPI tables, BIOS ROM, modified DSDT/SSDT and my current EFI folder. Thanks very much.
Attachments
Last edited by a moderator: