macOS boot.efi developer's thread

[splifingate]

commit 3747e95e (modded, twice)

MachO.cpp

1334: startAddress = loadedInfo->ImageBaseVirtualAddress;

1335: endAddress = 0xffffffffffffffff;

boot into createinstallmedia...output, attached

system hangs, indefinitely (t-eight minutes, and no-boot)...

...splifingate needs to gain sustenance, and rest…see all'y'all tommorrow....

[edit]

dang...I mis-read, and did not replace ImageBaseVirtualBase > ImageBasePhysicalBase...currently re-compiling/copying/re-booting...
[/edit]

[edit:edit]additional screencap, attached: edited MachO.cpp…still hangs at _ output...[/edit:edit]

[edit:edit:edit]modded boot.efi, attached[/edit:edit:edit]

 

[Pike R. Alpha]

Are you using the latest release of OS X (10.11.1) because 0x8a6000 is really 0x8a9000 in the kernels that I have here.

 

[clawfinger]

Can you make this change:

-startAddress = kldSegmentVirtualAddress;
+startAddress = loadedInfo->ImageBaseVirtualAddress;

Also. There is something I must be missing, because looking at the "Done @ 0x..." in your output. How got that less than the startAddress we give it?

Kernelpatcher: machOffset 0x0, machLength 0x67E6b92d05458000
Kernelpatcher: ASLRDisplacement 0x0
Kernelpatcher: physicalAddress: 0x200000
Kernelpatcher: virtualADdress.: 0xffffff8000200000
Kernelpatcher: kldSegmentVirtualAddress: 0xfffff8000b29000
Kernelpatcher: kldSegmentOffset........: 0x8a6000
Kernelpatcher: offset[0x950], startAddress[0xffffff8000b29000]
Kernelpatcher: Done @ [0x5f81001]

I'm not that well versed with the newish ASLR/PIE stuff, but aren't you overflowing a UINT64 here:

startAddress       + machLength         =   Done @ [0x5f81001]
0xffffff8000b29000 + 0x67e6b92d05458000 = 0x67e6B8ad0[5f81000]

feel free to ignore me, it's rather late (or early) here and I'm just catching up on the thread.

 

[Pike R. Alpha]

Kernelpatcher: machOffset 0x0, machLength 0x67E6b92d05458000
Kernelpatcher: ASLRDisplacement 0x0
Kernelpatcher: physicalAddress: 0x200000
Kernelpatcher: virtualADdress.: 0xffffff8000200000
Kernelpatcher: kldSegmentVirtualAddress: 0xfffff8000b29000
Kernelpatcher: kldSegmentOffset........: 0x8a6000
Kernelpatcher: offset[0x950], startAddress[0xffffff8000b29000]
Kernelpatcher: Done @ [0x5f81001]

I'm not that well versed with the newish ASLR/PIE stuff, but aren't you overflowing a UINT64 here:

startAddress       + machLength         =   Done @ [0x5f81001]
0xffffff8000b29000 + 0x67e6b92d05458000 = 0x67e6B8ad0[5f81000]

feel free to ignore me, it's rather later (or early) here and I'm just catching up on the thread.

The value of 'machLength' is wrong, set by MachLoadThinFatFile() so there is probably something broken in that function.

 

[splifingate]

Are you using the latest release of OS X (10.11.1)...

10.11.0; original app store release.

 

[Pike R. Alpha]

10.11.0; original app store release.

Right. That explains it. Thanks!

Edit: New commit available for compilation/testing.

 

[PeterHolbrook]

Trying to solve the puzzle.

Lines 881 and 882 of MachO.cpp moved to the beginning of the relevant function. LoadedInfo in line 1343 corrected to loadedInfo (lowercase initial).

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[randyoo]

Trying to solve the puzzle.

Lines 881 and 882 of MachO.cpp moved to the beginning of the relevant function. LoadedInfo in line 1343 corrected to loadedInfo (lowercase initial).

Commit cb42f388b, on USB installer running 10.11.0's kernel.

Don't know if it's relevant, but it seems to hang at this screen. Makes capturing a photo of the debug output much easier, at least!

 

[Pike R. Alpha]

Commit cb42f388b, on USB installer running 10.11.0's kernel.

Don't know if it's relevant, but it seems to hang at this screen. Makes capturing a photo of the debug output much easier, at least!

Thanks for testing this. And yup. I know. I was expecting it to hang.

New commit available for compilation/testing.

 

[PeterHolbrook]

Use KLD segment size.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[Pike R. Alpha]

We're now using the __KLD segment size, instead of the broken value of
machLength, and the value I have here in 10.11.1 is 0x19000/102400 but it may be different in 10.11.0 Doesn't really matter as long as the endAddress is correct. It should now also no longer hang.

 

[randyoo]

Use KLD segment size.

commit 117362...
(as before, USB installer made with "createinstallmedia", os 10.11.0)

 

[randyoo]

commit 117362...
(as before, USB installer made with "createinstallmedia", os 10.11.0)

It didn't hang, but I did get this nice kernel panic:

It's possible that this is caused by a corrupt USB stick, since I'm still using the same one that was causing problems earlier. No more time to test right now, though. I'll try formatting and re-creating later, if needed.

EDIT: after formatting and recreating the installer, got into installer GUI without seeing the KP again.

 

[Pike R. Alpha]

New commit available for compilation/testing.

Edit: I want boot.efi v3.1 to be released as soon as possible; v3.0 does not include the latest board-id and installer detection changes.

 

[PeterHolbrook]

Use __KLD segment physical address (not that of __TEXT).

Warning! Line 1351 of MachO.cpp amended to
*(UINT64 *)p = READ_STARTUP_EXTENSIONS_PATCH_UINT64;

Although this compiles, it might be entirely wrong! The original has *(UINT64 *)p = ;, which doesn't mean anything.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[Pike R. Alpha]

Use __KLD segment physical address (not that of __TEXT).

Warning! Line 1351 of MachO.cpp amended to
*(UINT64 *)p = READ_STARTUP_EXTENSIONS_PATCH_UINT64;

Although this compiles, it might be entirely wrong! The original has *(UINT64 *)p = ;, which doesn't mean anything.

I have no idea how I did that. Unnoticed change. Thanks for taking care of this error. Also fixed in the repo.

 

[randyoo]

Use __KLD segment physical address (not that of __TEXT).

Warning! Line 1351 of MachO.cpp amended to
*(UINT64 *)p = READ_STARTUP_EXTENSIONS_PATCH_UINT64;

Although this compiles, it might be entirely wrong! The original has *(UINT64 *)p = ;, which doesn't mean anything.

Commit 3f74cbc debug output attached.

 

[Pike R. Alpha]

Commit 3f74cbc debug output attached.

Thanks. Still failing.

The latest commit now includes debug output for the first and second kernel patch. The first one works so let's see what we get from it.

Edit: New commit with hardcoded search area available for compilation/testing. Use slide=0 (can be fixed later).

 

[PeterHolbrook]

Hardcoded search area.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[randyoo]

Hardcoded search area.

commit 1dd2ef...

This is all I get, then it hangs.

EDIT: Pike, I just realized I never cleared the NVRAM variable for bootarg slide=0 since you asked me to set it! I hope that doesn't mean that I've caused you unnecessary work now.

 

[randyoo]

Pike, please see the edit of my previous post. It turns out, I never cleared the "slide=0" boot-args NVRAM variable since last night. So all of my debug output today has been with that variable enabled. As said, I hope it doesn't mean I've been feeding you garbage.

I can clear the variable and go back and re-test previous commits, if that will help.

 

[splifingate]

Pike:

When I replace the boot.efi's, I have 'boot.efi' and 'bootbase.efi' in /Volumes/[legacy-BaseSystem.dmg-image]/System/Library/CoreServices . . . is it necessary to replace *both* with the newest commit every time?

It's rather tedious to do so, but I have been doing this with every commit....

 

[splifingate]

commit 1dd2ef72

#nvram boot-args="slide=0"

output from 10.11.0 createinstallmedia, legacy and Recovery HD:

Kernelpatcher: ASLRDisplacement 0x0
Kernelpatcher: physicalAddress: 0x200000
KernelPatcher: virtualAddress: 0xffffff8000200000

 

[Pike R. Alpha]

Ok this is not working. Let me change something. Done. New commit available.

@randyoo ,

Nope. It's good.

 

[clawfinger]

@splifingate and anyone else testing

Here's the script I made for my friend to do the myriad of bootloader replacements during our quest to get El Capitan installed on his Mac Pro 1,1 (successful as of commit 70f77b1 with Legacy USB).

You can edit the default path at the top, or pass a quoted (non-escaped) path on the command line.

I assume to replace both your USB drives you'd want to do something like this:

$ ./replaceBootloader "Install OS X El Capitan"; ./replacebootloader "[legacy-BaseSystem.dmg-image]"

and then it will be in your history as a one-shot. Just have it in the same directory as the latest boot.efi.

I hope it proves of some use to somebody.

-clawfinger

Edit: updated script to add 'xattr -d com.apple.quarantine boot.efi' per Pike's suggestion

Edit: the script now searches for a 'Recovery HD' on the same device as the provided Volume
(also squelched xattr output and fixed a bug with 'OS X Install Data')

Edit: rolled back the 'Recovery HD' support in the original 'replaceBootloader' script and moved it to a new script called 'replaceBootloaderWithRecovery' because some people have reported problems with it