Is Your Machine Good Enough for Snow Leopard K64?

“K64″ is what Apple refers to as the 64-bit version of the kernel beginning with Snow Leopard. As an end user, you really should not worry about the bitness of the kernel. If your Apple computer is not booting into K64 by default, you don’t need it—unless, of course, you know that you need it. (Say, because you are a kernel developer or an otherwise system-level developer and want to test something against a 64-bit kernel.) In particular, the 32-bit kernel, which is the default on most existing x86-based Apple computers, runs 64-bit applications just fine. Therefore, as long as you have a 64-bit processor, your Snow Leopard installation is 64-bit from the typical end-user standpoint.

An easy way to tell if you are running a K64 kernel is to use the uname command-line program. The "x86_64" in the excerpt below means that we are running a 64-bit kernel. If the output showed "i386" instead, that would mean a 32-bit kernel.

$ uname -a
Darwin... root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64

If you are averse to using command-line programs (Do you really care about a K64 kernel in that case?), you could instead launch the System Profiler application, either directly, or by clicking on "More Info…" in the "About This Mac" panel. In System Profiler, you can click on the "Software" section in the sidebar. There will be something about the presence or absence of 64-bit Kernel and Extensions. You could also launch the Activity Monitor application and look for kernel_task. The "Kind" column will say if the kernel task (and consequently the kernel) is 64-bit.

As alluded to earlier, a 64-bit processor is required to run a K64 kernel. To boot into K64, you could do one of several things:

  • Press the 6 and the 4 keys simultaneously at power-on time. This indicates to the EFI boot loader (boot.efi) that you wish to boot a 64-bit kernel.
  • Set the boot-args firmware variable, say, through the nvram command-line program. To boot K64, the specific command-line would be:
    $ sudo nvram boot-args="arch=x86_64"

  • Edit /Library/Preferences/SystemConfiguration/com.apple.Boot.plist and add arch=x86_64 to the value of the Kernel Flags key. By default, this value is an empty string.

    $ cat /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
    ...
    <dict>
    	<key>Kernel</key>
    	<string>mach_kernel</string>
    	<key>Kernel Flags</key>
    	<string>arch=x86_64</string>
    </dict>
    ...
    

Another way is to use the -setkernelbootarchitecture argument of the systemsetup(8) command-line program.

Additionally, you could tell the kernel to boot verbosely if you are interested in catching a 64-bit boot early on. Note that one of the early kernel messages is "64 bit mode enabled". This does not mean K64—it just means the kernel has identified the processor to be 64-bit and is going to use certain 64-bit features. In the case of a K64 boot, the message to look for is "Kernel is LP64".

Not so fast though.

Unfortunately, a 64-bit processor alone doesn’t suffice. Out of the box, boot.efi will not boot K64 even if you have a 64-bit processor and explicitly request K64 if at least one of the following is true.

  1. The machine has 32-bit EFI.
  2. The machine’s model is prohibited from booting K64 through a hardcoded list within the boot loader. (A cursory look suggests that the list excludes "non-Pro" machines.)

Both of these "limitations" are technically artificial, albeit to different degrees.

The first limitation actually does have merit and is arguably not all that artificial. Although a 32-bit EFI could launch a 64-bit kernel, the kernel, when running, would not be able to use firmware services. In particular, you wouldn’t have NVRAM. For kernel developers merely wanting to run a 64-bit kernel for testing and debugging, this may not be an issue, but it’s understandable why the limitation is in place.

The second limitation is annoying. As a developer, if you knowingly wish to boot into K64 to test something, you can’t on certain machines even though they are technically perfectly capable. I ran into this on a Unibody MacBook, which has 64-bit EFI but is not a "Pro" machine. Also, it’s ironic that you can, in fact, boot Snow Leopard into K64 on the very same computer when you run it as a guest operating system in a virtual machine.

If you really need to boot into K64 on such a machine with 64-bit EFI, you can—at your own peril—"fix" things within boot.efi by setting the appropriate bits in the hardcoded list of models. To ensure that we’re talking about the same multiarchitecture version of boot.efi, compare the SHA-1 checksum of that file.

$ shasum boot.efi
2fb9fc10e5b4bb06f62c38b01bd9836a433897f8    boot.efi

Then, change the 1 byte at the corresponding model-specific position in the following table to the corresponding new value. Rather than overwriting the original boot.efi, we will copy the original to a new file, say, boot-k64.efi, and edit the latter.

Model (with 64-bit EFI) Byte Position in boot.efi Old Value New Value
Mac mini 0x266D8 0x00 0x04
MacBook 0x266E8 0x00 0x04
MacBook Air 0x266F8 0x00 0x04
iMac 0x26718 0x08 0x0c

For the specific case of the MacBook, which is the only one I've actually tried, the before and after bytes will look like the following:

0x266E0:
38 47 01 00  00 00 00 00  00 00 00 00  00 00 00 00

0x266E0:
38 47 01 00  00 00 00 00  04 00 00 00  00 00 00 00

We'll place the boot-k64.efi file somewhere on the root volume—/System/Library/CoreServices/ is fine. Then, we need to reset volume bootability through the bless command-line program. Optionally, we can also set the ownership and user immutable flag on the file to "proper" values.

$ sudo cp boot-k64.efi /System/Library/CoreServices/
$ cd /System/Library/CoreServices/
$ sudo chown root:wheel boot-k64.efi
$ sudo chflags uchg boot-k64.efi
$ sudo bless --folder /System/Library/CoreServices \
  --file /System/Library/CoreServices/boot-k64.efi

Your mileage may vary depending on whether your installation has 64-bit versions of all necessary drivers for the model of your specific machine. Since I have not tried any other "excluded" machine besides a 64-bit MacBook, I don't know about other models. (Unavailability or instability of certain 64-bit drivers could be a plausible reason for these models to be excluded in the first place.)

If you do render your system unbootable, you can simply run bless again to restore volume bootability as it was before. That is, you can tell bless to use the original boot.efi. Of course, to do that, you'll need to either boot from a different volume (a system install disc would be fine), or be able to access and write to the unbootable volume from another computer.

$ sudo bless --folder /Volumes/BrokenMac/System/Library/CoreServices \
  --file /Volumes/BrokenMac/System/Library/CoreServices/boot.efi

Comments are closed.


All contents of this site, unless otherwise noted, are ©1994-2012 Amit Singh. All Rights Reserved.