slideでカーネル読み込み番地を調整する

macOSが起動するときに、早い段階で禁止マークが出て停止してしまうことがあります。多くの場合、カーネルを読込むメモリが確保できないエラーです。これをslideオプションで解決します。

症状

禁止マークが出て早々に起動停止してしまう場合に、-vオプションで起動すると、”Error Allocating xxxx pages at xxxxxxxx”というようなメッセージが出ていることがあります。例えば下のメッセージは、「0xe590000番地から0x11c01ページのメモリー空間を確保しようとしたけど失敗しました」という意味です。1ページは0x1000バイト、つまり4096バイトのことです。10進数を使ってわかりやすく書くと、「240メガバイトあたりの番地から298メガバイトくらいのメモリー空間を確保しようとしたけど失敗しました」といった感じのエラーです。100番台になってからのMSIマザーボードでよく発生するエラーです。

このエラーの特徴は、「何回か起動を試みるとそのうち成功することがある」とか、「大抵は起動するけどたまにこのエラーで起動しない」など、再現性が低いことです。

簡単な対策法

この問題を直してくれるのが以下のkextです。

  • AptioMemoryFix.efi
  • OsxAptioFix3Drv.efi
  • OsxAptioFixDrv.efi
  • OsxAptioFix2Drv-free2000.efi

以下の記事で説明したように、このリストの順番がお勧め順らしいので、上から試して、問題なく起動するkextを使います。一度に2個以上のkextを入れてしまうと、どちらが動くのか定まらないので避けるべきとのことです。

リストの上の方ほど新しく開発されたkextで副作用が少ないらしいです。一番強力なのが最後のOsxAptioFix2Drv-free2000.efiです。その名前の通りメモリーを強制的に開放させます。どのマザーボードでもほぼ機能する最強のkextです。でも強力すぎるので、大丈夫なのかという意見はあります。Redditには、OsxAptioFix2Drv-free2000.efiの利用は避けで、slideオプションで対応した方が良いという意見もありました。とはいえ、私もMSIのマザーボードでOsxAptioFix2Drv-free2000.efiを使い続けていますが、特に問題はありません。でもせっかくですので、slideを使った正しい解決策を試してみます。

カーネル読込に失敗する理由

KASLR (カーネル番地乱数化)

そもそもどういうことが原因で、カーネル読み込みに失敗するのかを調べました。macOSが起動する際に、カーネルが0x100000以降の番地(10進数で1,048,576、1MB程度です)のメモリーに読み込まれます。実際に何番地に読み込まれるかは定まってなく、ランダムです。上記のエラーの例では、カーネル(またはその一部)を0xe590000番地から始まるメモリー空間に読み込もうとして失敗しています。読み込み番地はセキュリティのためにわざとランダムにしているそうです。この仕組みを、KASLR (Kernel Address Space Location Randomization: カーネル番地空間場所乱数化) というらしいです。カーネルが読み込まれる番地が常に一定だと、その番地を狙って悪さを試みるマルウェアが可能です。特定の番地からプログラムを動かしたり、特定の番地の内容を書き換えることでOS動作を操れてしまうからです。そういう操作をされないために、起動毎に違う番地にカーネルを読み込んでいるそうです。

失敗しないマザーボード

以下で説明した方法で、UEFIシェルを起動すると、

マザーボードのメモリーマップを見ることができます。これに使うコマンドがmemmapです。memmap -bとすると画面いっぱいになったところで一旦停止してくれます。また、fs0:などでドライブを指定して、必要ならばcdコマンドで適当なディレクトリに移動した後、memmap > memmap.txt などとタイプすると、その場所にメモリーマップをテキストファイルで保存します。

AptioMemoryFix.efiなどの穏当なドライバで問題なく起動するマザーボードもたくさんあります。そのメモリーマップを見てみましょう。以下は、ASUSのZ390マザーボードの例です。(memmapの出力にはAttributesという項目もありますが、長くなるので省略してます。)

Type       Start            End              # Pages         
RT_Data    0000000000000000-0000000000000FFF 0000000000000001
Available  0000000000001000-000000000008FFFF 000000000000008F
RT_Code    0000000000090000-0000000000090FFF 0000000000000001
Available  0000000000091000-000000000009EFFF 000000000000000E
Reserved   000000000009F000-000000000009FFFF 0000000000000001
Available  0000000000100000-000000005315CFFF 000000000005305D
BS_Data    000000005315D000-0000000055101FFF 0000000000001FA5

ここを見ると、カーネルが読み込まれる可能性のある0x100000番地を先頭に、0x5315CFFF番地までが空き地になっていることがわかります。ページ数にして0x5305D番地の空き地です。1.4GBくらい空いているようです。最初に示したエラーメッセージによると、カーネル読み込みに必要なメモリー量は300MB程度らしいのです。なので、これだけ空いていれば、どの番地に読み込んでも順当にメモリー確保できます。おかげで、このマザーボードではメモリーアロケーションのエラーが出たことはありません。

ちなみいこの空き領域の容量は、起動するたびに多少変化することがあるようです。それでも変動は高々100MB程度です。また、iGPU割り当てメモリー量を変更してもほとんど変化しません。ASUSのメモリーマップはmacOSに適しているようです。

失敗するマザーボード

一方、最近のMSIマザーボードでAptioMemoryFix.efiなどを使うと、かなりの確率で起動しません。MSIはZ170チップセットモデルからOsxAptioFix2Drv-free2000.efiが手放せなくなってしまいました。どんなメモリーマップになっているのか見てみます。以下はB350Mマザーボードのメモリーマップです。最近のMSIマザーボードでは、どれもこんな感じのメモリーマップです。

Type       Start            End              # Pages         
BS_Code    0000000000000000-0000000000007FFF 0000000000000008
Available  0000000000008000-000000000005DFFF 0000000000000056
BS_Data    000000000005E000-000000000005EFFF 0000000000000001
Reserved   000000000005F000-000000000005FFFF 0000000000000001
BS_Code    0000000000060000-000000000009FFFF 0000000000000040
Available  0000000000100000-000000000FFFFFFF 000000000000FF00
BS_Code    0000000010000000-000000001000AFFF 000000000000000B
Available  000000001000B000-000000007751AFFF 0000000000067510
BS_Data    000000007751B000-000000007755AFFF 0000000000000040

ASUSとMSIのメモリーマップを比較してみましょう。0x100000番地から先のページ数で示しています。ASUSは0x100000番地から0x53000ページ以上が空き地です。しかしMSIは0x100000番地から0xFF00ページが空き地で、その後0xBページ(10進数で11ページ)が使われていて(小さすぎて図では見えません)、その後、0x67510ページが空いています。

つまり、MSIマザーボードでは、0x100000番地からは、0xFF00ページ、つまり267MB程度のメモリーしか空いていません。その後に、0x10000000番地から、たったの11ページ、バイト数にして45MBだけ、誰かが使っています。BS_Codeというのがそれです。そしてその後、0x1000B000番地から0x7751AFFF番地まで大量に空き地があります。そのため、0x100000番地から300MB程度を確保しようとすると、使用中の45MBが邪魔をして確保できません。これでエラーが出ます。なんでこんな邪魔なところに使用中のメモリーがあるんだ、という気持ちになります。

ただ、何度も何度も起動を試みると、たまに起動することもあります。エラーになるかどうかは、上で説明したKASLRが使用する乱数次第です。0x1000B000より大きい番地からメモリー確保しようとした場合は、エラーは出ず、問題なく起動します。

slideオプションで解決する

slideの仕組み

config.plistなどに書くmacOSの起動オプションの中で、slide=x などと書くと、メモリーを確保する開始番地を指定できます。その規則は次のようになっているそうです。つまり起動オプションにslide=xと書くと、

  • 最近のCPUでは、0x100000 + x * 0x200000が読み込み開始番地になります
  • ただし、SandyBridgeまたはIvyBridgeの場合は、xが0x80から0xFFまでは、上記の計算ですが、xが0x80から0xFFまでの場合、0x 10300000 + x * 200000になります

となることが知られてます。最近のCPUだけを考えれば、slide値を0x200000倍して0x100000を足すだけなので簡単です。以下ではこの計算が適用できるCPUを前提に説明を進めます。

空き地番地をSlideで指定する

上記のMSIマザーボードの場合、0x1000B000から、使われていないメモリーが大量にあるので、この番地以降を割り当てたいです。ということは、

0x100000 + x * 0x200000 = 0x1000B000
x * 0x200000 = 0x1000B000 - 0x100000 = 0xFF0B000
x = 0xFF0B000 / 0x200000 = 0x7F = 127

という計算になり、slide=127 (もしくはそれ以上の値)とすれば良さそうです。でもこの計算は切り捨てになっているので、実は127ではスライド量が足りません。127 (0x7F) の場合、

0x100000 + 127 * 0x200000 = 0xFF00000

からのメモリー確保がされるので、0x1000b000に引っかかってしまいます。1増やして128 (0x80) にすれば、

0x100000 + 128 * 0x200000 = 0x10100000

になるので、ようやく0x1000B000より大きな番地からの割り当てになります。つまりconfig.plistのBoot, Argumentに、以下のようにslide=128パラメタを追加すれば、このようなメモリー空き地が不連続な問題を回避できます。

<key>Boot</key>
  <dict>
    <key>Arguments</key>
    <string>slide=128 (他に必要なパラメータが続く)</string>

KASLRを無効にする

ブートオプションでslide値を指定しても、KASLRが効いているとslide値としては相変わらず乱数(0x00から0xFFまでの乱数)が割り当てられます。ブートオプションのslide値は無視されるようです。slide値を指定すると同時にKASLRを無効にする必要があります。

KASLRを無効にするためには、SIPでCSR_ALLOW_UNRESTRICTED_NVRAMフラグを立てる必要があります。これはNVRAMの変更制限を解除するフラグですが、同時にKASLRも解除されるようです。このフラグは、Appleが公開しているソースコードによると、

#define CSR_ALLOW_UNRESTRICTED_NVRAM	(1 << 6)

だそうです。1を6ビットだけ高位にシフトするという意味で、結果は0x40です。ということで、config.plistのRtVariables, CsrActiveConfigに0x40を書いておきます。

<key>RtVariables</key>
    <dict>
        <key>CsrActiveConfig</key>
        <string>0x40</string>
    </dict>

7ビット目が1ならば他の数字でも良いです。CsrActiveConfigとして、元々0x03という設定をされていたのであれば、0x43にすれば良いです。0x64という設定をしていたなら、これはすでに7ビット目が立っていますから、そのままで良いです。セキュリティをできるだけ確保するという観点からは、0x40が良いと思います。

これでブートオプションで指定したslide値が使用されるようになります。このようなconfig.plist設定で、MSIのマザーボードでもOsxAptioFix2Drv-free2000.efiを使わずに済むようになりました。AptioMemoryFix.efiで動きます。

ただ、CSR_ALLOW_UNRESTRICTED_NVRAMを許可すると、NVRAMの書き換えでSIPのすべての設定が変更可能になるので、セキュリティは脆弱になります。とはいえ、Hackintoshなのでconfig.plist書き換えて再起動すればSIPはどのようにも設定できるので、気にすることではないかもしれないです。さらにはslideパラメータでカーネル読み込みアドレスが固定されるのでKASLRの恩恵もなくなり、それも弱点になります。これに対しては、時々config.plistのslide値を微妙に書き換えて、人力KASLRしても良いかもしれません。

まとめ:マザボ別対処法

KASLRが機能していると、Slide値は0から0xFFまで乱数で設定されます。つまりカーネルが展開される先頭番地は、

0x100000 + 0 * 200000 = 0x100000 = 0番地から1MB程度先の番地

から

0x100000 + 0xFF * 200000 = 0x1FF00000 = 0番地から530MB程度先

になります。ここから、300MB程度の領域にカーネルが展開されるわけです。KASLRがどのようなslide値を指定しても、300MBのカーネルが読み込まれるためには、0x100000番地から900MB程度の空き地が必要ということになります。そこで0x100000番地からの空き地がどれくらいあるかによって次の対処法が考えられます。

なお、空き地容量の数値は、確保されるメモリーが300MB程度と仮定した場合の目安です。環境によってはもっと必要とされるかもしれません。

空き地が900MB以上あるマザボ

何もしなくて良いです。ASUSのマザーボードでは0x100000番地から1.4GBくらいの空き地がありました。なので、KASLRがどのように先頭番地を割り当てても平気です。SIPを弱めてKASLRを無効にする必要もありません。macOSに最適なメモリーマップを持つマザーボードと言えます。

空き地が300MB以下のマザボ

slideで空き地番地を指定します。MSIのマザーボードは、0x100000番地からの空き地が267MB程度しかありませんでした。次にある空き地が十分大きくてKASLRの範囲内にあるので、たまに起動しますが、大抵は起動に失敗します。このようなマザボでは、上記で説明したように、KASLRの範囲内にある300MB以上の空き地をslideで指定します。

空き地が300MB以上900MB未満のマザボ

slide=0にします。コメントで教えていただいたGIGABYTE Z390M GAMINGでは、0x100000番地からの空き地は480MBとのことです。この場合は、小さなslide値だと起動しますが(80以下程度)、KASLRで大きなslide値が指定されると失敗します。そこで、slide=0を指定して0x100000から必ず展開するように指定します。

27件のコメント

  1. お疲れさまです。
    興味深く、読みました。
    MACがMACであるゆえん(独自のロジックボードとBIOSを持つ)の問題なんですね。
    私のASUS PRIME H370-Aでも、
    Type  Start     End     # Pages    Attributes
    RT_Data 0000000000000000-0000000000000FFF 0000000000000001 800000000000000F
    Available 0000000000001000-000000000008FFFF 000000000000008F 000000000000000F
    RT_Code 0000000000090000-0000000000090FFF 0000000000000001 800000000000000F
    Available 0000000000091000-000000000009EFFF 000000000000000E 000000000000000F
    Reserved 000000000009F000-000000000009FFFF 0000000000000001 000000000000000F
    Available 0000000000100000-0000000070314FFF 0000000000070215 000000000000000F
    BS_Data 0000000070315000-0000000070354FFF 0000000000000040 000000000000000F
    Available 0000000070355000-000000007DFC7FFF 000000000000DC73 000000000000000F
    となっており、カーネルロード部分は断片化してないのですね。
     気になって沿革について調べてみました。
    OPEN BSDが2017年にロードのランダマイズを始めてから、LinuxやWindowsでも同様になっていたのですね。
    https://news.mynavi.jp/article/20170707-a082/
    https://qiita.com/satoru_takeuchi/items/5c80c4e255e21c5b4b8a
     Qiitaでは、「クラッカーが攻撃に使うコードやデータのアドレスを割り出すのが困難になります」とありますが、注釈に、「後述のKASLRも含め、困難ではありますが、不可能ではありません。クラッカーと防御側の攻防はいつでもいたちごっこなのです」とあるように、コード自体が動くということは、いずれにしてもカーネルの機能を呼び出してしまうので、終わりはないのですね。^^;
     大変面白かったです。

  2. お疲れさまです。
    起動時に何の問題もないマザーボードとエラーを出すマザーボードはメモリマップが違っていたのですね。
    早速手持ちのマザーボードのメモリマップをチェックしてみました。

    ASUS B365M-K
    Type Start End # Pages Attributes
    BS_Code 0000000000000000-0000000000007FFF 0000000000000008 000000000000000F
    Available 0000000000008000-0000000000057FFF 0000000000000050 000000000000000F
    Reserved 0000000000058000-0000000000058FFF 0000000000000001 000000000000000F
    Available 0000000000059000-000000000005EFFF 0000000000000006 000000000000000F
    BS_Data 000000000005F000-000000000005FFFF 0000000000000001 000000000000000F
    BS_Code 0000000000060000-000000000009EFFF 000000000000003F 000000000000000F
    Reserved 000000000009F000-000000000009FFFF 0000000000000001 000000000000000F
    Available 0000000000100000-00000000A85D4FFF 00000000000A84D5 000000000000000F
    BS_Data 00000000A85D5000-00000000A8614FFF 0000000000000040 000000000000000F
    Available 00000000A8615000-00000000B7F3CFFF 000000000000F928 000000000000000F

    GIGABYTE Z390M GAMING
    Type Start End # Pages Attributes
    Available 0000000000000000-000000000009EFFF 000000000000009F 000000000000000F
    Reserved 000000000009F000-000000000009FFFF 0000000000000001 000000000000000F
    Available 0000000000100000-000000001E130FFF 000000000001E031 000000000000000F
    BS_Data 000000001E131000-000000001E170FFF 0000000000000040 000000000000000F
    Available 000000001E171000-00000000341DBFFF 000000000001606B 000000000000000F
    LoaderCode 00000000341DC000-00000000343A8FFF 00000000000001CD 000000000000000F
    BS_Data 00000000343A9000-0000000036042FFF 0000000000001C9A 000000000000000F
    ACPI_NVS 0000000036043000-0000000036043FFF 0000000000000001 000000000000000F
    RT_Data 0000000036044000-0000000036044FFF 0000000000000001 800000000000000F
    BS_Data 0000000036045000-0000000036120FFF 00000000000000DC 000000000000000F
    Available 0000000036121000-0000000037F55FFF 0000000000001E35 000000000000000F
    BS_Data 0000000037F56000-000000003D1E8FFF 0000000000005293 000000000000000F
    Available 000000003D1E9000-000000003D34AFFF 0000000000000162 000000000000000F
    BS_Code 000000003D34B000-000000003DC1AFFF 00000000000008D0 000000000000000F
    Reserved 000000003DC1B000-000000003E07DFFF 0000000000000463 000000000000000F
    Available 000000003E07E000-000000003E481FFF 0000000000000404 000000000000000F
    ACPI_NVS 000000003E482000-000000003E5A1FFF 0000000000000120 000000000000000F
    RT_Data 000000003E5A2000-000000003EE4FFFF 00000000000008AE 800000000000000F
    RT_Code 000000003EE50000-000000003EEFEFFF 00000000000000AF 800000000000000F
    BS_Data 000000003EEFF000-000000003EEFFFFF 0000000000000001 000000000000000F
    Available 0000000100000000-00000004BDFFFFFF 00000000003BE000 000000000000000F

    ASUSマザーではエラーが発生しなかったのですが、0x100000から0xA84D5ページですから2.6GBくらい空いているのですね。これなら何も対策しなくて大丈夫でしょう。
    対してGYGABYTEマザーでは0x100000から0x1E031ページですから480MBくらいしか空いていません。ここに300MBを確保するためにslide=0が必要だったのだとよくわかりました。

    1. お疲れさまです。
      拝察いたしました。
       HackintoshではGIGABYTEは有名どころですよね。そのZ390ならと思うのですが。結構、意外な感じがします。
       GIGABITEとASUSは情報量が多いので、いずれかになりやすいですね。

  3. 貴重な情報ありがとうございます。私のマザーはyoshiiさんのと同じですが、ハードの構成が異なるせいか、メモリーマップは異なるようです。結果、CsrActiveConfig=0x43とslide=0の併用でclover5033付属のOsxAptioFix3Drvで安定して起動するようになりました。

  4. 貴重な情報ありがとうございます。Catalina Public Beta Testにおいて, メモリーパニックで悩まされている我がHacintosh環境にピッタリの、的を得たようなトピックで、助かりました。深く感謝いたします。

    当方のマザボは、ASRock Z170Mシリーズ製品(総量32GB搭載)です。当然、先進的なASUS 社製ではないところから判断して先手志向。
    まず手始めにClover Configuratorにて、以下の内容設定でTRY してみました。
    1) Boot-Argument: slide=128
    2) RtVariables: CsrActive  0x40
    その結果、0x100000番地から0x62675ページを空き地で確保できました。

    追記:さらに OpenCore Loader環境においても、同じ項目を全く同じ内容で設定完了。 
    これで、なんとか安定運用できそうです。

    補足:本当は、他のメンバーと同じく memmap > memmap.txt のShell コマンドで マップ全体のTEXT出力を得たかったのですが。どういうわけか’>’のキーがAppleキーボード上で見つからず!!  日本語JISキーボードに取り替えても同じように見つからず、やむなくGIVEーUP。(なぜなんでしょうか?)

    1. 私のBIOSも日本語JISキーボードを正しく扱わないため少々試行錯誤で色々叩くと大抵は見つかります。

    2. Shellコマンド使う時は英語キーボードが便利です。普段は使わないのですが1つあると便利ですよ。

    3. 普段からUSキーボードを使っていたので記号入力のことには気づきませんでした。

  5. 色々なマザーボードのメモリーマップを紹介いただきありがとうございます。グラフィックスボードに搭載されたBIOSもメモリーを確保するらしいので、マシン構成によって色々違うようです。

  6. 大変貴重な情報ありがとうございます。

    私はivyBridge3770+Z77 Mem32GB ASUS MaximusV
    という環境です。

    ところで本記事で改善された皆様は、セーフモードは起動しますでしょうか?
    Slide値をいくら弄っても、セーフモードは
    Start LoadKernelFromStream
    Error allocating 0x4770 pages at 0x0000000001010000 alloc type 2
    となって、Slide値が適応されていないように見えます。
    CsrActiveConfig値は以前の記事のリンク先で0x67が推奨されていたのでこのまま利用しており、
    問題ないことを確認しています。

    じゃぁ正常起動時のスタートアドレスは?っと思いましたがVerboseでも表示されないみたいでした。
    通常起動は問題ないです。

    長いですが参考までにアドレスマップを晒します。
    IvyBridgeということで、どうも最近のPCとは雰囲気が違っています。
    RT_Data 0000000000000000-0000000000000FFF 0000000000000001 800000000000000F
    Available 0000000000001000-000000000005EFFF 000000000000005E 000000000000000F
    BS_Data 000000000005F000-000000000005FFFF 0000000000000001 000000000000000F
    Available 0000000000060000-000000000008FFFF 0000000000000030 000000000000000F
    RT_Code 0000000000090000-0000000000090FFF 0000000000000001 800000000000000F
    Available 0000000000091000-000000000009DFFF 000000000000000D 000000000000000F
    Reserved 000000000009E000-000000000009FFFF 0000000000000002 000000000000000F
    Available 0000000000100000-0000000000FFFFFF 0000000000000F00 000000000000000F
    LoaderData 0000000001000000-00000000010FFFFF 0000000000000100 000000000000000F
    Available 0000000001100000-00000000C202FFFF 00000000000C0F30 000000000000000F
    LoaderCode 00000000C2030000-00000000C21FDFFF 00000000000001CE 000000000000000F
    Available 00000000C21FE000-00000000D67ABFFF 00000000000145AE 000000000000000F
    BS_Data 00000000D67AC000-00000000D6F95FFF 00000000000007EA 000000000000000F
    Available 00000000D6F96000-00000000D6F9FFFF 000000000000000A 000000000000000F
    BS_Data 00000000D6FA0000-00000000D6FA1FFF 0000000000000002 000000000000000F
    Available 00000000D6FA2000-00000000D6FA2FFF 0000000000000001 000000000000000F
    BS_Data 00000000D6FA3000-00000000DC550FFF 00000000000055AE 000000000000000F
    Available 00000000DC551000-00000000DCA2BFFF 00000000000004DB 000000000000000F
    BS_Code 00000000DCA2C000-00000000DD1CCFFF 00000000000007A1 000000000000000F
    Reserved 00000000DD1CD000-00000000DD4F1FFF 0000000000000325 000000000000000F
    Reserved 00000000DD4F2000-00000000DD72AFFF 0000000000000239 000000000000000F
    Reserved 00000000DD72B000-00000000DD730FFF 0000000000000006 000000000000000F
    Reserved 00000000DD731000-00000000DD795FFF 0000000000000065 000000000000000F
    ACPI_Recl 00000000DD796000-00000000DD79CFFF 0000000000000007 000000000000000F
    ACPI_Recl 00000000DD79D000-00000000DD7B8FFF 000000000000001C 000000000000000F
    ACPI_NVS 00000000DD7B9000-00000000DD835FFF 000000000000007D 000000000000000F
    ACPI_NVS 00000000DD836000-00000000DD8E0FFF 00000000000000AB 000000000000000F
    RT_Data 00000000DD8E1000-00000000DE062FFF 0000000000000782 800000000000000F
    RT_Data 00000000DE063000-00000000DE663FFF 0000000000000601 800000000000000F
    RT_Data 00000000DE664000-00000000DE665FFF 0000000000000002 800000000000000F
    RT_Data 00000000DE666000-00000000DE733FFF 00000000000000CE 800000000000000F
    RT_Code 00000000DE734000-00000000DE751FFF 000000000000001E 800000000000000F
    RT_Code 00000000DE752000-00000000DE7C6FFF 0000000000000075 800000000000000F
    BS_Data 00000000DE7C7000-00000000DE7C7FFF 0000000000000001 000000000000000F
    ACPI_NVS 00000000DE7C8000-00000000DE80AFFF 0000000000000043 000000000000000F
    BS_Data 00000000DE80B000-00000000DE95CFFF 0000000000000152 000000000000000F
    BS_Code 00000000DE95D000-00000000DEC00FFF 00000000000002A4 000000000000000F
    BS_Data 00000000DEC01000-00000000DEC1DFFF 000000000000001D 000000000000000F
    BS_Code 00000000DEC1E000-00000000DEC37FFF 000000000000001A 000000000000000F
    BS_Data 00000000DEC38000-00000000DEC38FFF 0000000000000001 000000000000000F
    BS_Code 00000000DEC39000-00000000DEC3AFFF 0000000000000002 000000000000000F
    BS_Data 00000000DEC3B000-00000000DEC41FFF 0000000000000007 000000000000000F
    RT_Data 00000000DEC42000-00000000DEFF3FFF 00000000000003B2 800000000000000F
    BS_Data 00000000DEFF4000-00000000DEFFFFFF 000000000000000C 000000000000000F
    Available 0000000100000000-00000007FEFFFFFF 00000000006FF000 000000000000000F
    MMIO 00000000F8000000-00000000FBFFFFFF 0000000000004000 8000000000000001
    MMIO 00000000FEC00000-00000000FEC00FFF 0000000000000001 8000000000000001
    MMIO 00000000FED00000-00000000FED03FFF 0000000000000004 8000000000000001
    MMIO 00000000FED1C000-00000000FED1FFFF 0000000000000004 8000000000000001
    MMIO 00000000FEE00000-00000000FEE00FFF 0000000000000001 8000000000000001
    MMIO 00000000FF000000-00000000FFFFFFFF 0000000000001000 8000000000000001

    1. SIRENさん、

       「本記事で改善されたユーザー」の一人です。
      Hacintosh環境に関しては、まだまだ初心者なので最初の質問だけに限定して、お答えいたします。

      Q1:セーフモードは起動しますでしょうか?
       Ansー> 先ほど、セーフモードで起動できるか否か試したら、起動OKでした。

      ーーーーーー
      追記: 差し支えなければ、後学のために少しお尋ねしてよろしいですか?
      私のマザボは最新の製品でないため、BIOSにはUEFI Shellが搭載されておらず、やむなくClover Bootloaderの起動画面にて、 UEFI Shellを起動して memmap コマンドを入力、そしてアドレスマップを画面に出すことができました。

      SIRENさんの場合は、文面を見ると何か別の方法でアドレスマップ情報を出力なさっているように見受けられますが、どのようにしていらしゃいますか?

      1. お返事ありがとうございます。
        セーフモード起動できるのですね〜御報告ありがとうございます。

        ぃぇぃぇ、Clover BootloaderからのUEFI Shellでのmemmapコマンドですよ。

    2. https://github.com/acidanthera/bugtracker/issues/444

      ここのvit9696さん(=AtpioMemoryFixの作者さん)が、
      「Hi, this issue can only cause issues entering safe mode on systems that cannot normally boot with slide=0, it cannot affect the installer. Thanks for the report though, we will handle it as time permits.」
      とセーフモードでエラーが出るのを認めてます。AptioMemoryFix使うのをやめるか、この問題を解決できるOpenCore に移行することが良いと思います。

  7. >ただし、SandyBridgeまたはIvyBridgeの場合は、xが0x80から0xFFまでは、上記の計算ですが、xが0x80から0xFFまでの場合、0x 10200000 + x * 200000になります
    申し訳ないのですが、この部分をもう少し知りたいです。Typoがある気がしていまして・・・。

    1. ご指摘ありがとうございました。計算ミスをしていました。
      > xが0x80から0xFFまでの場合、0x 10300000 + x * 200000になります
      に訂正します。記事も訂正しておきました。以下の書き込みに書いてある説明から式を作ったのですが0x100000を足しているところを見落としていました。

      https://www.insanelymac.com/forum/topic/331381-aptiomemoryfix/?do=findComment&comment=2564269

  8. Z390 AORUS PROをiMac19,1としてiGPU有効で使っているとほぼOsxAptioFix2Drv-free2000.efiを使わないと正常にブートしなかったので、UEFI Shellのmemmapコマンドで色々調べました。苦闘したのですが、

    1)iGPU用のメモリ確保を64mb以上にすると、どうやってもダメ。Slideを256の範囲で約400mb確保できる領域がどうしてもない。
      Slide値がすごい値になる領域しかなく、その値で設定してもダメ。above 4G decodingはメモリ確保には関係なさそう。
    2)iGPUのメモリを32mbに設定すると、0x100000番地から約400MB分のページ数を確保可能。
    ということでOsxAptioFix3Drv.efiで起動できることを確認しました。slide値はもちろん0。

    GIGABYTEのZ390 AORUSシリーズは海外フォーラムでもiMac19,1+iGPUオンでOsxAptioFix2Drv-free2000.efiを使うか、
    SMBIOSをiMacProに変更しiGPUをオフにする(それでメモリアロケーションを変化させる)ことで対応してることがほとんどです。多分当方のようにiGPUのメモリ確保を32mbに減らすことで対応できるのは良い情報です。BIOSのバージョンによっても微妙に
    メモリ領域は変化するようです。

    AptiomemoryFix.efiはDeprecatedされ、R27が最終版です。以降はOpenCoreに統合されて開発されるとのこと。
    Cloverを継続的に使うなら開発が続く?OsxAptioFix3Drv.efiを使うのが良いかもしれません。
     

    1. 興味深い情報をありがとうございます。記事で示したメモリーマップはZ390のASUS ROG MAXIMUS XI HEROでiGPUを128MBにした状態でした。メモリーマップ構成はASUSがmacOSと相性良いようですね。AptioMemoryFix.efiの情報もありがとうございます。参考になります。

    2. 情報ありがとうございます。
      ほぼ同じ構成ですので、頂いた情報を元にOsxAptioFix3Drv.efiで安定Bootするようになりました。

      bootmacosさんの当記事も大変勉強になりました、ありがとうございます。

  9. 私も色々と調べてみました。環境はZ390M gaming/i9-9900K/RX560です。当初、i9-9900KのiGPUを使って頑張っていましたが、HDMIの出力が不安定であるためRX560を追加してそっちに鞍替えです。表示に用いているのはRX560のDPです。iGPUをBIOSでdisableにすると上手く起動しますが、enableにするとメモリー割当に失敗します。0x100000からのメモリーは皆さんとほぼ同様で、iGPUのDVMTメモリーがデフォルトのpre-allocated=64M,max=256Mのとき以下のような具合です。

    Available 0000000000100000-0000000016F14FFF 0000000000016E15 000000000000000F
    BS_Data 0000000016F15000-0000000016F54FFF 0000000000000040 000000000000000F
    Available 0000000016F55000-000000002AFBBFFF 0000000000014067 000000000000000F

    割当るのは0x1198bページのためslide=0とすると0x100000からの割当が成功して起動できそうに見えますが、実際には0x5c70000で割り当てられなかったとして止まります。pre-allocated=32Mにすると割当は成功しますが、その後panic.apple.comを表示して停止です。pre-allocatedの値を大きくすると、その分だけ0x100000からの領域が縮小し、隣接するBS_Data以降のアドレスがその分下へと移動します。もちろん割り当てには失敗します。
    次に0x100000の次のAvailableから割り当てるようにslide=192としてみました。計算上、実際のアドレスは0x18100000となります。やはり割り当てに失敗するのですが、今度は0x1dc70000で失敗したとのこと。0x1dc70000-0x18100000=0x5b70000であり最初に失敗したときは、0x5c70000-0x100000=0x5b70000でオフセットは一緒です。つまりは0x5b70000=95879168ですから
    slideで指定したアドレスから約100MB上のアドレスから割り当てようとしている模様です。0x5b70000/0x1000=0x5b70ページが追加で必要となり、これと0x1198bを加えると0x174FBとなって最初の領域に収まりません。これを収納できるAvailableな領域は0x100000000となり、slide=2048となって8ビットのslide値では届きません。試してところやはり駄目でした。ということでiGPUの使用は諦めです。
    なかなか奥が深くて手強い…

    1. SIPが有効だとKASLRが優先されることに気づかないで何度か失敗して、エラーをたくさん記録したことがあります。その時に気付いたのですが、どうも何回かに分けてメモリー確保をしているようです。たまにいつもと違うページ数の確保に失敗したというメッセージが出てました。オフセットが同じということですので、オフセットが0x5b70000までのメモリー確保は成功したけど、その後、大きめの領域を確保しようとして、失敗しているのかもしれません。GIGABYTE(ですよね)のそのマザーボードだと、slideで調整可能な範囲のどちらの空き領域も、実は足りないということなのかもしれません。
      記事では300MB必要らしいと書きましたが、実はもっと必要なのかもしれないと思っています。

      ちなみにpre-allocatedはどこの設定でしょうか?BIOS?知らなかったので調べてみます。

      1. マザーボードはGIGABYTEです。pre-allocatedはBIOSの設定値です。Z390M gamingではiGPUをenableにするとDVMTのサイズ設定ができるようになります。pre-allocatedとmaxの指定が出来ます。どうやらiGPUに前以て割り当てるメモリーと最大値の模様です。調べた限り(=memmapで見る)ではpre-allocatedで指定した領域はアドレススペースの上方に確保されるようですが、実際にしわ寄せを受けるのは一番下(=0x100000)の領域です。pre-allocated=32Mとするとこの領域のページ数は0x18e15であり、64Mでは0x16E15、また256Mでは0xAE15となります。差分はpre-allocatedの差分そのものです。この領域の2つ上にあるAvaiableのページ数はpre-allocatedに関わらず0x14067で一定です。BIOS設定値であるpre-allocatedを変えると二番目以降のAvaiableのアドレスが変わるので、二番目以降にloadする場合にはslide値もそれに応じて修正を必要とします。
        先にも書きましたたが、iGPUを使う場合はOSの領域の手前にさらに100MB程度が必要なようです。私の環境ではそのような領域が8bitのslideで表現できる範囲にはありません。
        そこで一旦諦めたのですが、そうはいかないみたいです。どうやらiGPUをdisableにするとjpegファイルを処理できなくり、結果、プレビューがハングします。pdfはOKですが、jpgは駄目でした。そこで元々使っていたOsxAptioFix2Drv-free2000.efiを入れたところ、起動するようになりました。jpegもOKです。いやはや、奥が深いですね。

        1. iGPUを無効にした時にJPEGのクイックルックやプレビューが動かなくなる問題は、ブートオプションに以下を追加すると直るかもしれないです。

          shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94

          こちらをご覧ください。

          https://bootmacos.com/entry/2019/07/24/203055

          Gigabyteのメモリーマップは厄介ですね。まだ0x100000のちょっと上に確実に大きな空き地のあるMSIの方がマシなのかな。AUSUS > MSI > GIGABYTEの順で、macOSに適したメモリー配置を持っているような気がしてきました。ASRockはどのような感じでしょうか?>ユーザの皆様

          1. GIGABYTEしか使ったことがないので他は分かりませんが、今回は非常に手こずりました。数年前に初めて作った時はtonymacx86で紹介?しているボードとuni/multibeastで一発動作でしたが、今は違うみたいです。忍耐力がない人にはGIGABYTEは向かないと思います。

            1. BIOS時代はGIGABYTE一択だったのですが、事情が変わった感じがしますね。今はASUSが推奨でしょうか。ASRockはどうなのかな。

  10. お疲れさまです。
    古いASUS B75M-Plus,i7 3770K,Geforce 1050Tiで問題がありました。
    Reserved 000000000009E000-000000000009FFFF 0000000000000002 000000000000000F
    Available 0000000000100000-0000000000FFFFFF 0000000000000F00 000000000000000F
    LoaderData 0000000001000000-00000000010FFFFF 0000000000000100 000000000000000F
    Available 0000000001100000-00000000CACC0FFF 00000000000C9BC1 000000000000000F
    たった0x1000000-10FFFFFにカーネル配置できない部分があります。
    0x100000+ x * 0x200000=0x1100000
    x * 0x200000 = 0x1100000-0x100000=0x1000000
    x = 0x1000000 / 0x200000=0x08
     ランダムシード値が0~7のときに起きるんですから、本当にまれなのですが、やっぱりそういうときもあるんですね。
     slide=8
     及び、
     RtVariables, CsrActiveConfigを0x40で行けました。
    この情報は本当に有用ですねぇ。感心しました。

    1. お役に立てて何よりです。私はこの記事を書くために調べるまで、KASLRのことを知らなかったので、起動に成功したり失敗したりする再現性の無い振る舞いが謎でした。たまにしか失敗しない場合は、無対策のまま起動に失敗しても、車のエンジンをかけるのに失敗したような気持ちで、再起動し直すという手もあるかもです。

スマの辰五郎 にコメントする コメントをキャンセル

メールアドレスが公開されることはありません。

「名前」「メールアドレス」「サイト」は空白でも投稿できますが、日本語が含まれない投稿は無視されます。(スパム対策)