![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-11-30T09:02:17+09:00;2024-11-30T06:39:17+09:00","default:kaw","kaw") #author("2024-11-30T15:53:55+09:00","default:kaw","kaw") #topicpath *河豚板のIBT対応 [#te955453] RIGHT:EBUG 第91回会合 2024年11月30日 ~ 川俣吉広、kaw@on.rim.or.jp **概要 [#a554226a] 河豚板にて同様の不具合が複数報告されたことにより調査・対応を行った。 -amd64プラットフォーム版の河豚板{7.5,7.6-current,7.6}にて発生 -起動時、カーネルのdmesgが出力し終わり、/boottmp/rcが実行されるタイミングで発生 -"Process (pid 1) got a signal 4"が繰り返し表示され、起動完了しない。 **経過要約 [#wbc378d4] **経過 [#wbc378d4] |9月22日 (日) |karl | ''初の報告'' (on Hyper-V) | | |kaw | 現象を分析、initがsignal 4 (SIGILL)を受けるのはHyper-V特有の問題か | |10月20日 (日)| | ''[[FuguIta/Report/19]] にて同様の報告''が上げられる。| | |masakazu,kaw|コンパイラのCPUインストラクションセットの指定の問題である可能性を議論| |||(河豚板7.6リリース)| |10月21日 (月)|kaw |PIEが関連しているか検討| | |kaw,karl|pie:PIEな版→現象かわらず| |10月23日 (水)|kaw,karl|rvmk:ビルドツールの改修版→現象かわらず| |10月24日 (木)|kaw,karl|init: /boottmp/initを独立した実行バイナリにした版→/bin/shが起動しない| |||''新たに報告あり。[[FuguIta/Report/23]]'' - 12th Gen Intel(R) Core(TM) i3-1220P| | |karl |クランチバイナリの問題？''12世代以降''のP/Eコア構成が絡んでいるか| |10月25日 (金)|paina |''12900K 実機によるテスト''→現象再現(Process (pid 1) got signal 4)、E-Core を無効にしても発生| | |kaw,karl|tst4:クランチバイナリ生成部を現行のOpenBSD本家を基に作り直し→現象変らず。single user shでのコマンド実行が明らかにおかしい。| |10月27日 (日)|kaw,karl|tst5: crunchgen廻りをよりOpenBSDに近づけた版| | |kaw,karl|tst6: *.[do]の消し忘れがあったので改良版を生成、NKPTPも増やす| |10月28日 (月)|kaw,karl|nocb: クランチバイナリを使用しない版→/bin/shは起動できた。sedなどがcore dumpする。| | |kaw |本件についてfuguita.orgの掲示版で広報| | |karl |''[[arm64で関連する可能性のある事例を検索>https://github.com/golang/go/issues/66040]]''| | |nork |''[[コンパイル時のリンカーオプションに -Wl,-z,nobtcfi の指定を示唆>https://isopenbsdsecu.re/mitigations/forward_edge_cfi/]]''| |10月29日 (火)|karl |LDFLAGS+=$(NOPIE_LDFLAGS) -z nobtcfiを追加してbootbinをビルド、起動できたが、core dumpしてるものがある。| | |kaw |IBT対応は[[OpenBSD Journal>https://www.undeadly.org/cgi?action=article;sid=20240222183703]] と[[OpenBSD公式>https://www.openbsd.org/innovations.html]]で紹介されていた。| | |kaw |cts2: LDFLAGS+=-Wl,-z,nobitcfiでビルドしたバージョン → /boottmp/rc内でSIGILL発生| |10月30日 (水)|karl |再度処理が走るのでshell自身がcore dumpしているのではないようだ。| | |kaw |シェル変数が未代入、sysctlとかswapctlがcore dumpしているかも。| |10月31日 (木)|kaw,karl|cts4: クランチバイナリを /usr/src/distrib に倣って作ってみた版→signal4 で落ちる| | |karl |/boottmp/init？がIBTで保護されて、バイナリが起動できないのでは| |11月1日 (金) |karl |現象の整理| | |kaw |/usr/ports に、Makefileで USE_NOBTCFI = Yes という定義をしているものがある| |11月2日 (土) |kaw,karl|cts7:OpenBSDでの instbin ビルドを河豚板の bootbin に適用→メモリ取得でcore dumpする(cts6と同様)| | |kaw,karl|cts8: build-repl.sh で作成。中身的には cts7 と同じ→ルートディレクトリに、''sh.core ができている''| | |kaw,karl|Jitsiにてミーティング| | |kaw |cts9: /boottmp/rc の冒頭に set -x を付けた版| | |karl |HYPER-V上では、cpuid 7.0の所にedx=bc104410 <MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD>と、IBTが立っている。| | |kaw |コアダンプしているのは''クランチバイナリのswapctlか、それを起動しているコマンド実行置換のサブシェルの可能性が高い''。| | |karl |$swpmem=NULLとなり、NULLを参照して落ちるのでは。| | |kaw |parsesize はシェル関数なので、NULLを参照して落ちる、ということはないと思う。| |11月3日 (日) |kaw |検索: [[脆弱性緩和技術の最前線 - CPU レベルの技術>https://www.ffri.jp/assets/files/research/research_papers/recent_advances_vuln_mitig_jp.pdf]]| | |kaw |ctsa: makeconf.awkのlibs行の生成部分をlibs -Wl,-nopie -Wl,-z,nobtcfi -lutilに変更した版、 printfデバッグを追加| | |karl |wd0bが存在する状態でもスワップ容量は取れていない| | |kaw |ctsb: ctsa から 2>/dev/null をはずした版→swapctlは正常に実行されて、値も取得されいるようだ| | |kaw,karl|ctsc: set -v を追加, swpmemを設定する部分をスキップ→ctsc: parsesize 75% 2031 0を渡してもサブシェルがIllegal instruction(core dumped)する。| | |karl |シェルコマンド置換の部分で、評価順序に依っては問題が起きるのではないか。| | |kaw |パラメータのコマンド実行置換(=サブシェル)がネストするとコケる、っていうことでは。| | |karl |カーネル内で、''option SMALL_KERNELによるIBT無効部分を特定''| | |kaw,karl|ネストしたシェル呼出しのサンプルコードを提示→HYPERV on OpenBSD 7.6では正常| | |kaw |ctsd: bootbinにノーマルなkshを入れた版→file system fullに| | |kaw,karl|ctse: ramdisk root容量増、NKPTP変更、起動初期にksh起動版→シェルスクリプト実行中に落ちる| |11月5日 (火) |kaw |実機を手配| |11月6日 (水) |karl |自前buildで検証→IBT環境でcrunch バイナリを実行する時は、nobtcfiが必須と推測| |11月7日 (木) |kaw |crunchgenが不正な分岐命令を生成していると推測→nobtcfiが必要| | |kaw |実機到着・テスト実施| |11月8日 (金) |kaw |テストシェルスクリプト(クランチバイナリ)→''シェルのネストで死ぬ''| | |kaw |ctsf: /boottmp/bootbinに-z nobtcfiを付けてビルド&init, sh (=ksh) は個別のバイナリ→''正常に起動''| | |karl |同様に、''正常起動を確認''| | |kaw |[[FuguIta/Report/19]]、[[FuguIta/Report/23]] の報告者にも追試を依頼| | |kaw |''FuguIta-7.6-amd64-202411081を対応版としてリリース''| |11月9日 (土) |kaw |i386カーネルが動作せず→NKPTP変更でOK。全プラットフォームでOK| **要約 [#e12409d8] -当初はHyper-V固有の問題と認識 -実機での報告が複数寄せられたことから、本格的に対応を開始 -エラーメッセージから、発生箇所はクランチバイナリである/boottmp/initと推測 -コンパイラが生成するCPUのインストラクションセットの可能性を検討 -PIEが関係しているか検討 -12世代以降のCPUでのP/Eコア構成が絡んでいるか検討 -CFI(Control Flow Integrity)機能を持つCPU(amd64: IBT, arm64:BIT)との関連を検討~ →CFIに関するリンカオプション(-z nobitcfi)を発見 -OpenBSD 7.4以降でCFIに対応したことが判明 -IBT無効としたクランチバイナリをビルド~ →当初のメッセージは出なくなるが、一部でコアダンプ~ →コアダンプしたコマンドを調査 -OpenBSDのインストーラでは、option SMALL_KERNELによりIBTを無効としていることが判明 -テストスクリプトを作成、実機にて調査~ →クランチバイナリのshでは、IBT無効でビルドしても、このshをネストして起動するとコアダンプすることが判明 -shのみ個別のバイナリとしてビルド → 対応版をリリース **まとめ [#i99fc495] -EBUGで複数のメンバーがコラボレーションして成果を出した初めての事例ではないか --参加者各位様、ありがとうございました。 -この事象はOpenBSD 7.4のリリース以降が該当しており、事実、河豚板 7.4でも発生する --複数の報告が寄せられたのは、河豚板7.6リリースの直前 → 不具合報告の体制を要見直し -このようなケースではOpenBSD本体との連携をどのように考えるか //--派生プロジェクトに対するOpenBSDプロジェクトの姿勢を見るに、直接の連携は難しい --派生プロジェクトに対するOpenBSDプロジェクトの姿勢を見つつ、連携について考慮する必要がある ---- #topicpath
