博士

ロボ子、今日のITニュースはシャドウスタックじゃ！バックトレースが高速になるらしいぞ。

ロボ子

バックトレースの高速化ですか。それは興味深いですね、博士。バックトレースは、プログラムのエラーを特定するのに不可欠なツールですが、確かに時間がかかることがあります。

博士

そうじゃろう？今までは、スタックからフレームを復元するために、巨大なDWARFセクションを読み込んでいたからの。CPUキャッシュに優しくないポインタチェイスも問題じゃった。

ロボ子

DWARFセクションは確かに大きいですね。それがシャドウスタックでどう変わるのですか？

博士

シャドウスタックは、リターンアドレスだけを格納する特別なスタック領域を作るんじゃ。CALL/RET命令の時だけ書き込むようにして、スタックバッファオーバーフローを防ぐセキュリティ機能でもあるんじゃぞ。

ロボ子

なるほど、リターンアドレスを別の場所に保存することで、元のスタックを辿る必要がなくなるのですね。IntelのCETやAMDのZen 3でハードウェアサポートもされているとのこと。

博士

そう！Linux 6.4からサポートが追加されて、GCCでコンパイルオプションを指定すれば使えるようになるんじゃ。`SHSTK`が`.note.gnu.property`に追加されるのが目印じゃな。

ロボ子

glibcも関連しているようですが、何か制約があるのでしょうか？

博士

glibcは、ハードウェアがシャドウスタックをサポートしているか検出して、有効/無効を切り替える役割があるんじゃ。でも、Zen 3のハードウェア検出がまだだったり、全てのライブラリがシャドウスタック対応でコンパイルされてないとダメだったり、アプリケーション起動時に環境変数でしか設定できなかったり、色々課題があるみたいじゃ。

ロボ子

なるほど、まだ発展途上なのですね。glibcを使わずに実装する方法もあるのでしょうか？

博士

カーネルのselftestを参考に、syscallを直接使えば、ランタイムでシャドウスタックを切り替えられるぞ。ただし、`makecontext()`, `swapcontext()`, `longjmp()`みたいなカスタムコンテキストスイッチングロジックを使っている場合は、シャドウスタックポインタの保存と復元が必要になるから注意じゃ。

ロボ子

syscallを直接使うのは少しハードルが高いですが、柔軟性は高そうですね。ハードウェアサポートされたシャドウスタックは、高速なバックトレースを実現する強力な機能ですが、ソフトウェアサポートはまだ改善の余地がある、という結論ですね。

博士

その通り！これからの発展が楽しみじゃ。…ところでロボ子、シャドウスタックって、なんだか忍者の隠れ身の術みたいじゃないか？

ロボ子

確かに、リターンアドレスを隠すという点では似ているかもしれませんね。でも、忍者は物理的に姿を隠しますが、シャドウスタックは論理的にリターンアドレスを保護します。

博士

うむ、まあ、どっちも「見えなくする」って意味では同じ…って、やかましいわ！