「あ…ありのまま 昨夜起こった事を話すぜ！」
「おれは kernelビルドが終わったので自鯖を再起動したら サーバが起動しなくなってしまった」
「な…何を言っているのかわからねーと思うが おれも何が起きたのかわからなかった…」
「頭がどうにかなりそうだった…」
「ビルド失敗だとかGRUB記述ミスだとかそんなちゃっちなもんじゃあ断じてねえ」
「もっと恐ろしいものの片鱗を味わったぜ……」
kernelパニックになるならデバッグ次第でなんとかなるのでマシなのだが何故かパニックにならず、
GRUBを読み込んだ後にブラックアウトしたまま、CPU使用率100%でブン回るだけだった。
手がかりと言えば、ブラックアウトする直前に表示されるコンソールが1行。
文章からして、kernel-4.15.0で入ったmeltdown/specter対策のコード暴走かと思い、
GRUBに [pti=off spectre_v2=off] を追加して起動してみたが、CPU使用率は上がったままだった。
「とりあえず、kernelのソース読んで見るか」とプログラムを読めもしないのに読んでみた。
結果、どうやら下記の「retpoline_auto」辺りのソースが怪しい事がわかった。
retpoline_auto:
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
retpoline_amd:
if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
pr_err("LFENCE not serializing. Switching to generic retpoline\n");
goto retpoline_generic;
}
mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_AMD : SPECTRE_V2_RETPOLINE_MINIMAL_AMD;
setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD);
setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
} else {
retpoline_generic:
mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC : SPECTRE_V2_RETPOLINE_MINIMAL;
setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
}
spectre_v2_enabled = mode;
pr_info("%s\n", spectre_v2_strings[mode]);
}
|
ちなみに、ns-labの自鯖ホスト機はIntelが1機・AMDが2機稼働している。
今回のテスト機が動いているのはAMDホストサーバの方だったので、
『な～んか、CPUエミュレーションしている箇所も怪しいな…』という事と、
CPUベンダーの判定箇所で転けているっぽい事まではわかった。実際の原因は違うのですが…
そもそもの、meltdown/spectre脆弱性はCPUハードウェア設計が起因の多岐に渡る脆弱性ではあるのだが、
AMDのCPUに限って言えば、AMDの公式見解が下記の通りあった。
- meltdownはIntelCPUのみ対象
- Spectre Veriant1はOSレイヤの対応、
- Spectre Veriant2はAMDも対象だが悪用は極めて困難
ただ、前途の通りGRUBでmeltdown/spectreの対応コードをオフにしてもダメだった事から、
大元となる原因は他に存在すると仮説を立てつつ、他の切り口を調べてみた。
振り出しに戻ってしまったので、GRUBの起動オプションに [loglevel=7] も追記してリトライ。
すると「random: crng init done」が出た直後に無限ループに入っている事が判明。
このエラーはラズパイでSDカードのファイルシステムが壊れた際に出やすいので、
『まさかHDDクラッシュ……？』と思ったのだが、ファイルシステムが壊れる予兆は全く無かったのと、
kernelを切り戻すと普通に起動する事から違う問題と仮定。
原因が全くわからないので、最後の手段であるLinuxMLをググってみた。
結果、それっぽい事がバグ報告が見つかった (｀・ω・´)
斜め読みした所、kernelのメモリ管理をスパース行列にした際、
QEMUのブートプロセスがランダムにハングアップするバグと書いてあった。
kernelが起動しなくなった自鯖環境はQEMUでエミュレーションしているのと、
メモリ管理はスパース型にしている事から状況にも合致しており、恐らくコレが原因だろうと推測。
不具合の起きた、kernel-4.15.2はstableだったが、上記バグ報告はkernel-4.15.0だった。
なんとなく『kernel-4.15.2にマージされていないのかなぁ～』と思い、
ビルドオプションはkernel-4.15.2と同じままで、kernel-4.15.0に下げてみたら普通にサーバが起動した。
………
業務利用とかでkernelビルドする事は(少なくとも自分は)あまり無いと思うが、
今回の不具合を経験してMLとログの重要性を再認識した。
こんな事が出来るのも自鯖のメリットなので、
楽するのが一番だけれども、自鯖位なら敢えて茨の道を突き進むのもアリだなと思った。
…と、記事を書いていたらkernel-4.16.0rc1が出ていたのでバグが直っているか早速ビルド中。
どうなるかは、本日の筆者twitterをご確認ください ﾍ(ﾟ∀ﾟﾍ)
kernel-4.16.0-rc1で入れ直したら起動出来ました。どうやら、バグコードが修正された模様。
« 続きを隠す
