racerrehabman

Just some techie stuff

Mavericks/Haswell Kernel Patch for Early Reboot

with 55 comments

One of the big changes for mach_kernel in OS X Mavericks is the relocation of CPU power management into the kernel (for Haswell only). What used to happen in AppleIntelCPUPowerManagement.kext, now happens in the kernel. Since this kernel writes to potentially locked MSRs, this can be a problem for computers where the BIOS cannot be patched, or simply where the owner of the computer does not want to patch the BIOS. But since Apple did not include the code to XCPM (XNU CPU Power Management) in the sources provided for the 10.9 kernel, if you build mach_kernel from sources, the XCPM code and thus the code writing to locked MSRs is not included. I wrote about this initially when I discovered it while trying to get Mavericks running on a Haswell-based HP laptop. See here: http://www.insanelymac.com/forum/topic/293503-haswell-early-reboot-mavericks-locked-msrs-and-hp-envy-15-j063cl-i7-4700mq/

As mentioned in that post, my reason for building the kernel myself was to explore the possibility of removing the code that manipulates these locked MSRs. Of course, I couldn’t find the code because Apple didn’t provide it. To my surprise, the kernel built without this code still worked and I was able to coble together a system which provided power management by using patched AppleIntelCPUPowerManagement.kext from 10.8.5 and this rebuilt from source mach_kernel. That success put the idea of finding a patch to the included kernel on hold. But my real goal was to eventually come up with a patch.

My prior attempts to do this had not worked. My attempt was to patch the kernel such that only writes to MSR 0xE2 were filtered out. But then Pike blogged about the possibility of eliminating all writes to MSRs (https://pikeralpha.wordpress.com/2013/11/23/experimental-bin-patch-for-maverick/), and even though he was targetting the wrong section of code (_wrmsr_carefully is not called, at least not by mach_kernel itself), and I was misunderstanding his post such that I thought he was targetting the correct section of code (see below), I tried the approach of filtering out all writes to locked MSRs. This worked (in fact I commented on his blog with a perl patch that does exactly that), so I wondered if the problem was that there were MSRs other than 0xE2 being written to that were also locked. This turned out not to be the case. The problem was my original patch was simply not done correctly. But the breakthrough was realizing that I was targetting the right section of code, and that my patch must be in error or incomplete.

This is the code in mach_kernel that poses the problem (otool -tV mach_kernel):

ffffff80002f9ba0 pushq %rbp
ffffff80002f9ba1 movq %rsp, %rbp
ffffff80002f9ba4 movl %edx, %r8d
ffffff80002f9ba7 testl %esi, %esi
ffffff80002f9ba9 je 0xffffff80002f9c17
ffffff80002f9bab addq $0x28, %rdi
ffffff80002f9baf nop
ffffff80002f9bb0 movl _xcpm_cpu_model(%rip), %eax
ffffff80002f9bb6 testl 0xffffffffffffffdc(%rdi), %eax
ffffff80002f9bb9 je 0xffffff80002f9c0f
ffffff80002f9bbb movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9bbe testl %r8d, %r8d
ffffff80002f9bc1 je 0xffffff80002f9bcb
ffffff80002f9bc3 cmpl %r8d, %ecx
ffffff80002f9bc6 movl %r8d, %ecx
ffffff80002f9bc9 jne 0xffffff80002f9c0f
ffffff80002f9bcb rdmsr
ffffff80002f9bcd movl %eax, %eax
ffffff80002f9bcf shlq $0x20, %rdx
ffffff80002f9bd3 orq %rax, %rdx
ffffff80002f9bd6 movq %rdx, 0xfffffffffffffff8(%rdi)
ffffff80002f9bda movq 0xffffffffffffffe8(%rdi), %rax
ffffff80002f9bde testq %rax, %rax
ffffff80002f9be1 je 0xffffff80002f9be9
ffffff80002f9be3 notq %rax
ffffff80002f9be6 andq %rax, %rdx
ffffff80002f9be9 orq 0xfffffffffffffff0(%rdi), %rdx
ffffff80002f9bed movq %rdx, %r9
ffffff80002f9bf0 shrq $0x20, %r9
ffffff80002f9bf4 movl %edx, %eax
ffffff80002f9bf6 movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9bf9 movq %r9, %rdx
ffffff80002f9bfc wrmsr
ffffff80002f9bfe movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9c01 rdmsr
ffffff80002f9c03 movl %eax, %eax
ffffff80002f9c05 shlq $0x20, %rdx
ffffff80002f9c09 orq %rax, %rdx
ffffff80002f9c0c movq %rdx, (%rdi)
ffffff80002f9c0f addq $0x30, %rdi
ffffff80002f9c13 decl %esi
ffffff80002f9c15 jne 0xffffff80002f9bb0
ffffff80002f9c17 popq %rbp
ffffff80002f9c18 ret
ffffff80002f9c19 nop
ffffff80002f9c1a nop
ffffff80002f9c1b nop
ffffff80002f9c1c nop
ffffff80002f9c1d nop
ffffff80002f9c1e nop
ffffff80002f9c1f nop

At 2f9bfc, you can see the wrmsr. This has the potential to write to any register as this function is walking through a table of entries, each 48 bytes in size, where the each entry contains the register to write to.

Note that there are seven nop codes following the function (padding), which gives us room to grow the function by 7-bytes to add additional code to filter out the writes that might be MSR 0xE2. My first attempt was to simply try a compare/conditional jump:

                 cmp 0xE2, %ecx
                 je skipwrmsr
ffffff80002f9bfc wrmsr
skipwrmsr:
ffffff80002f9bfe movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9c01 rdmsr
ffffff80002f9c03 movl %eax, %eax

The problem is fitting the two new instructions into only 7 bytes. I could not find a way (problem is a cmp byte-immed,%ecx is a sign extending compare).

Instead, I decided to simply check for zero in the table and then modify the table to zero out the entries with 0xE2:

                 testl %ecx, %ecx     ;85 c9
                 je skipwrmsr         ;74 07
ffffff80002f9bfc wrmsr
ffffff80002f9bfe movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9c01 rdmsr
skipwrmsr:
ffffff80002f9c03 movl %eax, %eax

Because we are inserting 4-bytes of extra code to implement this, a few other conditional jumps must be modified. It is useful to add some labels to the original code and add the opcodes as comments before attempting to build a perl script for the patch:

ffffff80002f9ba0 pushq %rbp                           ;55
ffffff80002f9ba1 movq %rsp, %rbp                      ;48 89 e5
ffffff80002f9ba4 movl %edx, %r8d                      ;41 89 d0
ffffff80002f9ba7 testl %esi, %esi                     ;85 f6
ffffff80002f9ba9 je 0xffffff80002f9c17 ;return1       ;74 6c
ffffff80002f9bab addq $0x28, %rdi                     ;48 83 c7 28
ffffff80002f9baf nop                                  ;90
loop1:
ffffff80002f9bb0 movl _xcpm_cpu_model(%rip), %eax     ;8b 05 5e 30 5e 00
ffffff80002f9bb6 testl 0xffffffffffffffdc(%rdi), %eax ;85 47 dc
ffffff80002f9bb9 je 0xffffff80002f9c0f ;continue1     ;74 54
ffffff80002f9bbb movl 0xffffffffffffffd8(%rdi), %ecx  ;8b 4f d8 45
ffffff80002f9bbe testl %r8d, %r8d                     ;85 c0
ffffff80002f9bc1 je 0xffffff80002f9bcb ;skip1         ;74 08
ffffff80002f9bc3 cmpl %r8d, %ecx                      ;44 39 c1
ffffff80002f9bc6 movl %r8d, %ecx                      ;44 89 c1
ffffff80002f9bc9 jne 0xffffff80002f9c0f ;continue1    ;75 44
skip1:
ffffff80002f9bcb rdmsr                                ;0f 32
ffffff80002f9bcd movl %eax, %eax                      ;89 c0
ffffff80002f9bcf shlq $0x20, %rdx                     ;48 c1 e2 20
ffffff80002f9bd3 orq %rax, %rdx                       ;48 09 c2
ffffff80002f9bd6 movq %rdx, 0xfffffffffffffff8(%rdi)  ;48 89 57 f8
ffffff80002f9bda movq 0xffffffffffffffe8(%rdi), %rax  ;48 8b 47 e8
ffffff80002f9bde testq %rax, %rax                     ;48 85 c0
ffffff80002f9be1 je 0xffffff80002f9be9 ;skip2         ;74 06
ffffff80002f9be3 notq %rax                            ;48 f7 d0
ffffff80002f9be6 andq %rax, %rdx                      ;48 21 c2
skip2:
ffffff80002f9be9 orq 0xfffffffffffffff0(%rdi), %rdx   ;48 0b 57 f0
ffffff80002f9bed movq %rdx, %r9                       ;49 89 d1
ffffff80002f9bf0 shrq $0x20, %r9                      ;49 c1 e9 20
ffffff80002f9bf4 movl %edx, %eax                      ;89 d0
ffffff80002f9bf6 movl 0xffffffffffffffd8(%rdi), %ecx  ;8b 4f d8
ffffff80002f9bf9 movq %r9, %rdx                       ;4c 89 ca
additional_code:
                 test %ecx,%ecx                       ;85 c9
                 je skip_rdmsr                        ;74 07
ffffff80002f9bfc wrmsr ;0f 30
ffffff80002f9bfe movl 0xffffffffffffffd8(%rdi), %ecx  ;8b 4f d8
ffffff80002f9c01 rdmsr                                ;0f 32
skip_rdmsr:
ffffff80002f9c03 movl %eax, %eax                      ;89 c0
ffffff80002f9c05 shlq $0x20, %rdx                     ;48 c1 e2 20
ffffff80002f9c09 orq %rax, %rdx                       ;48 09 c2
ffffff80002f9c0c movq %rdx, (%rdi)                    ;48 89 17
continue1:
ffffff80002f9c0f addq $0x30, %rdi                     ;48 83 c7 30
ffffff80002f9c13 decl %esi                            ;ff ce
ffffff80002f9c15 jne 0xffffff80002f9bb0 ;loop1        ;75 99
return1:
ffffff80002f9c17 popq %rbp                            ;5d
ffffff80002f9c18 ret                                  ;c3
ffffff80002f9c19 nop                                  ;90
ffffff80002f9c1a nop                                  ;90
ffffff80002f9c1b nop                                  ;90
ffffff80002f9c1c nop                                  ;90 ;; remove these 4 nops
ffffff80002f9c1d nop                                  ;90
ffffff80002f9c1e nop                                  ;90
ffffff80002f9c1f nop                                  ;90

As you can see, because the jump targets have moved, the conditional jumps at 2f9ba9, 2f9bb9, 2f9bc9, and 2f9c15 must be adjusted to accomodate the extra four bytes of code. My first attempt (prior to building the kernel from sources) only adjusted the last one (oops).

The final perl patch is as follows:

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x5e\x30\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3\x90{3})\x90{4}|\x74\x70${1}\x74\x58${2}\x75\x48${3}\x85\xc9\x74\x07${4}\x75\x95${5}|g' mach_kernel

With that patch in place, the resulting patched function looks like:

ffffff80002f9ba0 pushq %rbp
ffffff80002f9ba1 movq %rsp, %rbp
ffffff80002f9ba4 movl %edx, %r8d
ffffff80002f9ba7 testl %esi, %esi
ffffff80002f9ba9 je 0xffffff80002f9c1b
ffffff80002f9bab addq $0x28, %rdi
ffffff80002f9baf nop
ffffff80002f9bb0 movl _xcpm_cpu_model(%rip), %eax
ffffff80002f9bb6 testl 0xffffffffffffffdc(%rdi), %eax
ffffff80002f9bb9 je 0xffffff80002f9c13
ffffff80002f9bbb movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9bbe testl %r8d, %r8d
ffffff80002f9bc1 je 0xffffff80002f9bcb
ffffff80002f9bc3 cmpl %r8d, %ecx
ffffff80002f9bc6 movl %r8d, %ecx
ffffff80002f9bc9 jne 0xffffff80002f9c13
ffffff80002f9bcb rdmsr
ffffff80002f9bcd movl %eax, %eax
ffffff80002f9bcf shlq $0x20, %rdx
ffffff80002f9bd3 orq %rax, %rdx
ffffff80002f9bd6 movq %rdx, 0xfffffffffffffff8(%rdi)
ffffff80002f9bda movq 0xffffffffffffffe8(%rdi), %rax
ffffff80002f9bde testq %rax, %rax
ffffff80002f9be1 je 0xffffff80002f9be9
ffffff80002f9be3 notq %rax
ffffff80002f9be6 andq %rax, %rdx
ffffff80002f9be9 orq 0xfffffffffffffff0(%rdi), %rdx
ffffff80002f9bed movq %rdx, %r9
ffffff80002f9bf0 shrq $0x20, %r9
ffffff80002f9bf4 movl %edx, %eax
ffffff80002f9bf6 movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9bf9 movq %r9, %rdx
ffffff80002f9bfc testl %ecx, %ecx
ffffff80002f9bfe je 0xffffff80002f9c07
ffffff80002f9c00 wrmsr
ffffff80002f9c02 movl 0xffffffffffffffd8(%rdi), %ecx
ffffff80002f9c05 rdmsr
ffffff80002f9c07 movl %eax, %eax
ffffff80002f9c09 shlq $0x20, %rdx
ffffff80002f9c0d orq %rax, %rdx
ffffff80002f9c10 movq %rdx, (%rdi)
ffffff80002f9c13 addq $0x30, %rdi
ffffff80002f9c17 decl %esi
ffffff80002f9c19 jne 0xffffff80002f9bb0
ffffff80002f9c1b popq %rbp
ffffff80002f9c1c ret
ffffff80002f9c1d nop
ffffff80002f9c1e nop
ffffff80002f9c1f nop

But that just allows us to replace the 0xE2 (or any MSR value) in the tables with zero such that it is never written to. But we need a patch to change the data tables.

One such table is here (xxd<mach_kernel):

062bc80: e200 0000 0200 0000 0000 0000 0000 0000 ................ ; _xcpm_core_scope_msrs (begin) esi=3
062bc90: 0004 0000 0000 0000 0700 001e 0000 0000 ................
062bca0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
062bcb0: e200 0000 0c00 0000 0000 0000 0000 0000 ................
062bcc0: 0004 0000 0000 0000 0500 001e 0000 0000 ................
062bcd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
062bce0: e200 0000 1000 0000 0000 0000 0000 0000 ................
062bcf0: 0004 0000 0000 0000 0800 007e 0000 0000 ...........~....
062bd00: 0000 0000 0000 0000 0000 0000 0000 0000 ................ ; _xcpm_core_scope_msrs (end)

The patch for this table (three entries) is:

perl -pi -e 's|\xe2(\x00{3}\x02\x00{12}\x04\x00{6}\x07\x00{2}\x1e\x00{20})\xe2(\x00{3}\x0c\x00{12}\x04\x00{6}\x05\x00{2}\x1e\x00{20})\xe2(\x00{3}\x10\x00{12}\x04\x00{6}\x08\x00{2}\x7e\x00{20})|\x00${1}\x00${2}\x00${3}|g' mach_kernel

With these two patches in place, you can boot OS X with the (patched) mach_kernel even when register 0xE2 is locked.

Update #1

I managed to find a 5-byte opcode for (non-sign extend) cmpw $e2,%cx:

            cmpw    $00e2,%cx               ;66 81 f9 e2 00
            je  skip3                   ;74 02

Note that we are comparing cx here, not ecx, so we are comparing only the low-order 16-bits of ecx instead of the full 32-bits. But in all cases, the high-order 16-bits or ecx in this case are always zero (refer to the tables referenced by esi and passed to this function). Not surprising, since MSR register values are not that large.

The side benefit of this is no patching is necessary to the data tables that drive this function, and the rdmsr is allowed to execute.

As such, the following single perl patch can be used instead:

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x5e\x30\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g' mach_kernel

Note: It uses all seven “spare” nop codes at the end of the function. But a closer look at this code reveals a poorly optimized function anyway. For example there are two instances of movl %eax,%eax:

ffffff80002f9bcd    movl    %eax, %eax              ;89 c0 (like a nop)
...
ffffff80002f9c03    movl    %eax, %eax              ;89 c0 (like a nop)

Note that even the simplest post-codegen optimizer should be able to remove such code.

And the reload of ecx after wrmsr is not necessary:

ffffff80002f9bfe    movl    0xffffffffffffffd8(%rdi), %ecx      ;8b 4f d8 (not necessary!)

So there is actually seven extra bytes for a total of 14 that could be used for extra code here.

Update #2

This patch is also applicable to the 10.8.5 kernel. I haven’t tested it, but the code is exactly the same (and at the same location) in the 10.8.5 kernel.

Note also that the Clover team has added this patch as an automatic on-the-fly patch. Just set “KernelPm” to true in the your config.plist (same section as “KernelLapic” would go).

Update #3

Scratch that on the 10.8.5 kernel. It is slightly different (I got my USB sticks confused!). I will provide an updated patch in a jiffy…

Update #4

Here is the 10.8.5 patch (not tested, but code review looks ok). I will test this later when I have a chance to install 10.8.5 on my laptop.

perl -pi -e 's|\x74\x69(\x48\x83\xc7\x28\x90\x8b\x05\xfe\xce\x5f\x00\x85\x47\xdc)\x74\x51(\x8b\x4f\xd8\x45\x85\xc0\x74\x05\x44\x39\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x9c(\x5d\xc3)\x90{7}(\x90{3})|\x74\x70${1}\x74\x58${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x95${5}${6}|g' mach_kernel

Update #5

You may have noticed that Apple has recently released 10.9.1. There are two versions of the 10.9.1 update, one for the new Haswell MacBookPro11,x (retina) laptops and another for the rest. The one for Haswell retina machines has a new mach_kernel, version 13.0.2. The code has changed only slightly but still requires a new patch.

The changed patch is as follows:
perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x46\x37\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g' mach_kernel

There are only two bytes different in the search pattern, but since these two bytes are likely to change in each release of the kernel, it probably makes sense to use a wildcard for them. Here is a modified patch that works on both current 10.9 kernels (13.0.0, 13.0.2… what happened to 13.0.1?):

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05..\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g' mach_kernel

Update #6

The same patch provided above works for the 10.9.2 mach_kernel (13.1.0).

Advertisements

Written by racerrehabman

2013/11/25 at 05:28

Posted in Computers

Tagged with , , ,

55 Responses

Subscribe to comments with RSS.

  1. Good work man. But you can not make a script something like this AICPMPatch.pl but instead patching the Appleintelcpupowermanagment patch the mach_kernel

    STINGA11

    2013/11/25 at 13:22

  2. Do we have to apply the update 1 too ? which men the three perl patches

    mmmprod

    2013/11/25 at 21:44

    • Or in fact this last perl can replace the two other perl patches

      mmmprod

      2013/11/25 at 21:58

    • Update #1 is a replacement for the two perl patches in the main article. It is an alternate way to do (almost) the same thing.

      racerrehabman

      2013/11/25 at 22:07

  3. Wish there were more blogs like this one. Could use some pictures to keep it interesting lol (My blog is overly filled with pictures XD).

    I’m currently woking on a unibeast/myHack/kakewalk opensource alternative for Linux. Would you mind if I incorporated this patch into it? Also could I redistribute some of your kexts through it? You’ll get credit of course :)

    donovan6000

    2013/11/26 at 01:02

    • I’m not much for formatting or pictures. It took me way too long to make that post, mostly because of random weirdness that wordpress was doing to my formatting (basic stuff like blank lines getting removed and such). I’m not a word processor/html/formatting expert… I struggled with even the simplest task… code blocks… and finally settled on using ‘pre’ tags. It is probably not the best way, but at least it uses a fixed pitch font. I’m really more of a C++/x86/C/etc kind of guy. All this HTML crap is not my thing.

      And yes, I’m ok with distributing my open source projects as long as credit is given. And it is not a bad idea to include a link to the source repo at github.

      As for this patch, it is a work-in-progress. I’ll probably still be tweaking it. But both versions I’ve posted do appear to work, at least with the current 10.9 kernel (no telling what happens with future versions).

      racerrehabman

      2013/11/26 at 02:06

      • Rehabman – thanks for your work on this. I have a Haswell NUC arriving next week and plan on installing Mavericks via Unibeast (after swapping to the patched Kernel for the installer itself to avoid the initial reboot cycle) and then booting the install trying the latest Clover revision (which I believe is r2352 and should contain one of your patches) at first boot. Just to be clear, I assume it is the property under “KernelCpu” under “KernelAndKextPatches” in the config.plist that needs to be set to “YES” to implement an on the fly patch. Does that sound right to you?
        Again, many thanks!

        laserhive

        2013/12/07 at 10:44

  4. Ignore my last comment please – I have seen your remark re. “KernelPm”. Don’t understand why my brain did not register that when reading it earlier.

    laserhive

    2013/12/08 at 05:39

  5. racer you are the man! Thank you so much for ur hard work. I keep seeing post after post in tonymacx86 of uyou helping people. The world could use more people like you. Thank you!

    Migue

    2014/01/12 at 15:50

    • Not sure how long I can keep it up, but you’re welcome (for now).

      racerrehabman

      2014/01/14 at 07:40

      • Can you tell me how to patch using the codes above? Sorry I’m quite new in this kind of thing.

        Pandasloth

        2014/02/21 at 19:16

      • Use copy/paste in Terminal.

        racerrehabman

        2014/02/26 at 13:56

  6. Hey Rehabman, what is the perl code for patching the 10.9.2 kernel?

    uj

    2014/02/27 at 00:12

  7. I keep getting …

    “-bash-3.2# syntax error near unexpected token ‘\x48\x83\xc7\x28\x90\x8b\x05..’ ”

    Keep in mind I’m trying to do this inside Terminal on the Mac OS installer (I changed the directory in terminal to my installed HDD)

    What am I doing wrong? Are those ‘..’ typos in the code? Thanks

    SwampFoxy

    2014/03/13 at 02:34

    • Weird. Found a way to copy and paste into terminal in the installer. Still tells me there is a syntax error (even without the periods) and at the same line as well.

      SwampFoxy

      2014/03/13 at 03:53

      • Not sure what you mean by ‘line’… The patch is a one-liner.

        racerrehabman

        2014/03/13 at 07:46

    • Not typos.

      racerrehabman

      2014/03/13 at 07:45

      • Hello, I`m very sorry to bother you like this. I have been searching for succesful builds with this motherboard for a while now and you seem to be one of the few that got it working as it should.
        I have the same motherboard, i7 2600, and a Nvidia geforce 460 gtx card. I`m just wondering if it is worth putting on a mac OS on a machine thats a bit old already, and how much of a problem do you think it would be.
        Best regards
        Jernej

        Jernej

        2014/03/24 at 08:56

      • I have Mavericks working perfectly on my DH67GD. Requires DSDT patches (at my github repo). You should have no issues using the same procedure with your DH67BL. The board is very stable with OS X.

        racerrehabman

        2014/03/26 at 17:23

  8. hey Racerrehabman,

    great job, are you a really good sky man. I was also a very good one, practicing in The French Alpes when I was young… Grenoble, Albertville and all around… ;-)

    Then we are not here to speak about me, nor skiing (do not want to annoy anyone…)

    First of all my config :

    ————————————————-
    DELL XPS 15 9530
    motherboard : DELL – DDR3 SD-RAM 16 Go
    Chipset : Haswell
    Processor : i7-4702HQ @ 2.2 GHz
    HDD 1 To
    SSD 32 Go RAM
    Mouse : external
    3 USB 3.0 ports
    1 USB 2.0 port
    2 graphic Cards : Intel HD4600 + NVidia GeForce GT 750 M (dont know how it switches from one to the other !)
    ————————————————-

    I may say that, at this time, the only solution I found to make my DELL working, is in patching the mach_kernel the way you indicated (but I’m only able to start the installer, install Mavericks, and then never be able to make it start on the hard drive (one test with a partition on my hard drive 1 To, and one test on the 32 Go SSD, gave the same results) even if I also copy the kernel on the / repertory of my hard drives)

    Nevertheless, I didn’t know exactly what I had to do : I mean I only use the first patch.

    Trying something else didn’t seem to work (I tried to use 2 patches one after the other on the same kernel as you said in your example, but it didn’t work.)

    ———————————————————————————————————–
    What works for starting the USB Drive installer (from Unibeast) : (and only with -x -f)
    ———————————————————————————————————–

    ———————————————————————————————————————-
    # in Terminal, assuming your USB is called Installer
    cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel_backup
    cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel
    cd ~/Desktop
    # now copy/paste one or more of the perl patches from above into Terminal

    # for xpcm related panic/reboot 10.9.x kernel
    perl -pi -e ‘s|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05..\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g’ mach_kernel

    # patched mach_kernel is now at ~/Desktop/mach_kernel
    sudo cp mach_kernel /Volumes/Installer/mach_kernel
    ———————————————————————————————————————-

    ————————————-
    What doesn’t work ;
    ————————————-

    ———————————————————————————————————————-
    # in Terminal, assuming your USB is called Installer
    cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel_backup
    cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel
    cd ~/Desktop
    # now copy/paste one or more of the perl patches from above into Terminal

    # for xpcm related panic/reboot 10.9.x kernel
    perl -pi -e ‘s|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05..\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g’ mach_kernel

    # for Local APIC panic (also causes instant reboot) 10.9.x kernel
    perl -pi -e ‘s|(\x25\x1c\x00\x00\x00\x48\x8d\x0d..\x5e\x00\x3b\x01)\x74(\x11\x48\x8d\x3d…\x00\x44)|${1}\xeb${2}|g’ mach_kernel

    # patched mach_kernel is now at ~/Desktop/mach_kernel
    sudo cp mach_kernel /Volumes/Installer/mach_kernel
    ———————————————————————————————————————-

    I can also say that it never works everytimes, and that it seems to be a randoming situation… sometimes the installer starts, sometimes it ends up with a “no entry” icon (“prohibited direction” icon)

    Do you think my problem is coming from PM, or do I have to search something else ?
    How to use ‘-v’ flag as it immediatly reboots and I can’t see what is the final problem ?

    Thanks for your help.

    Great regards.

    Mac

    Martin SWART

    2014/03/22 at 06:25

    • You probably have a graphics issue. Make sure you remove the nvidia kexts (NVDA*, Geforce*) and start with IntelAzulFB=12 GraphicsEnabler=Y dart=0.

      racerrehabman

      2014/03/26 at 17:21

  9. Sorry…I messes up…wrong topic. I`m building a an intel dh67bl hackintosh.

    Jernej

    2014/03/24 at 08:58

  10. WOW MAN YOUR ROCK

    Anthony Blomfield

    2014/04/05 at 16:38

  11. Hey rehabman, I didn’t want to highjack your post here so I tried to PM you on the Tonymac site but I don’t have the minimum required post for it.
    RehabMan,

    I noticed in your signature over there that you have a Lenovo U430 Touch, i7-4500U (nearly identical set up to the flex 15 with the i7 4500U) with 10.9.3 installed. How did you manage to pull it off?

    I just purchased a Lenovo Flex 15 and I’m having a hell of a hard time hacking it while keeping the original Windows 8.1 installation as well. I’ve managed to get 10.9.3 installed with Clover, but can’t get the bootloader installed on the EFI partition “installation failed”, using Legacy mode I get the boot0af: error.
    Using Unibeast with the Haswell Patched Mach_kernel I can get 10.9.3 installed but run into kernel panic trying to access the installation HD to install Chimera. The keyboard is crazy during the setup with unibeast making terminal commands nearly impossible to type.

    Any help would be greatly appreciated.

    Thanks,

    Ron

    Ron

    2014/05/20 at 18:25

    • Use a more recent version of Clover to install to the /dev/disk0s2 where the EFI partition is (SYSTEM_DRV). Or install Clover manually, as I did before the change to the Clover installer was made.

      racerrehabman

      2014/06/04 at 06:14

  12. What about a 10.9.3 patch ?

    Tom Pouce

    2014/05/22 at 22:24

  13. How to patch mach_kernel on Ivy Bridge
    GA-Z77X-UD3h
    i7 3770K
    GTX580

    crushers1982

    2014/05/29 at 06:09

    • No need on Ivy unless you’re using -xcpm kernel flag. On Ivy, PM is done in AppleIntelCPUPowerManagement.kext.

      racerrehabman

      2014/06/02 at 10:06

  14. Hi dude,
    great work i have os x running on my probook 4530s. one question though, can i use the via port for presentations using a projector. if yes please give me the directions. thanks a bunch.

    kibasui g-tau

    2014/06/01 at 12:47

    • What do you mean by ‘via port’?

      racerrehabman

      2014/06/02 at 10:08

      • typo– via VGA port

        kibasui g-tau

        2014/06/04 at 00:17

      • If you used the ProBook Installer… it patches AppleIntelSNBGraphicsFB to enable VGA. You have to hold Option in SysPrefs->Displays to reveal the “Detect Displays” button. It doesn’t work for all devices since OS X support for VGA is half-baked, but it might work.

        Personally, I’d use HDMI and an active HDMI->VGA adapter.

        racerrehabman

        2014/06/04 at 06:11

  15. rehabman,
    please update the guide with yosemite kernel patch.
    thanks

    prafsoni

    2014/06/04 at 10:43

    • Not until it is released. I already did the necessary changes in Clover, so you can use that.

      racerrehabman

      2014/06/05 at 08:53

      • Can you maybe link the clover fix? I am also looking for a fix. Would patching the yosemite kernel with the 10.9.3 patch even work? Would an AMD patch work?

        ajthemacboy

        2014/06/06 at 15:24

      • The patch for 10.9.x will not work. AMD patches would be for AMD computers — if your computer is Intel, you should not use an AMD kernel.

        The Clover fix is available via the KernelPm option and is in the current build. I build Clover from source, so I don’t even know where builds are kept (I’m sure you can find it with google). For building from source: https://github.com/JrCs/CloverGrowerPro.

        racerrehabman

        2014/06/06 at 18:17

  16. First I want to thank you so much for the patch, it works great with Mountain Lion. Great work. However I was not successful with Mavericks: it seems like on June 30th Apple released 10.9.4, and that is the only version I could get from them after I bought Mac OSX and upgraded to Mavericks. Have you had a chance to test (or update) your patch on 10.9.4? Thanks!!!

    Mike

    2014/07/04 at 05:41

  17. Please help me….. getting this after some kexts get loaded. patched in the above method.
    https://app.box.com/s/mjqe1uw7l9n4531ffbis

    Dinesh Kumar L N

    2014/08/09 at 09:33

    • You need to patch mach_kernel for “Local APIC” (lapic) panic.

      racerrehabman

      2014/08/11 at 07:41

      • that worked. installation complete. But i cannot boot up post installation.system reboots, after reading hfs+files. instant reboot with no screeen hang. any Help??

        Dinesh Kumar L N

        2014/08/13 at 14:46

      • After a fresh install, the OS X installer has placed unpatched mach_kernel at /mach_kernel. You need to copy the patched version there.

        racerrehabman

        2014/08/16 at 14:21

  18. Hi rehabman. What about Ivy bridge EP (xeon) V2 ?

    In 10.9.1 your kernel patch worked for me with that cpu . Trying with 10.9.2 and clover, seems automatic kernelPM patch works fine ( I saw the log) . I can use native kernel. But, I have a poor performance (slow, very slow).

    So I´ve decided try with 10.9.3 and 10.9.4, with hope to get best IB EP v2 cpus support. But , when I try to instalI (any of them) I got same KP I had with 10.9.1 installation without pached kernel ( just before of installer, it goes to blank). I suppose maybe automatic clover pm patch doesn´t work with 10.9.3 and 10.9.4.

    I´m a liitle confused about use an haswell patch with my IB EP v2, I don´t know if I’m doing the right thing , but it seems works. Should I try to patch 10.9.3 / 10.9.4 kernel and try to use it to fix KP during installing process?

    very very grateful

    J.

    2014/08/16 at 16:18

    • I have no Ivy EP hardware. My understanding is Xeon/X79 and such similar hardware can be tricky, especially wrt to power management.

      racerrehabman

      2014/08/22 at 15:15

  19. Hi Rehabman,

    I have a problem with my machine .. It failed to turn on after the battery died.
    I have a HP probook 4530s i3..

    I get this error…. Please help me out all my files are at risk..

    kibasui g-tau

    2014/08/18 at 05:09

  20. i am using 10.8.5. after security update , kernel has been updated 12.6.0 from 12.5.0.
    is there new patch for Darwin Kernel version 12.6.0 ?

    mildcat

    2015/05/19 at 06:19


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: