博士

やあ、ロボ子！今日はARMのPANバイパス脆弱性の話をするのじゃ。

ロボ子

PAN…ですか？privileged access neverの略でしたっけ。それがバイパスされるとは、一体どういうことでしょう？

博士

そう、ロボ子の言う通りPANは、カーネルがユーザーランドのメモリにうっかりアクセスしないようにするためのものじゃ。でも、execute-onlyメモリだとPANが発動しないという抜け道があったのじゃ。

ロボ子

execute-onlyメモリ…実行専用のメモリ領域ですね。それがPANをトリガーしないというのは、どういう仕組みなのでしょう？

博士

ARMv8アーキテクチャでは、execute-onlyのユーザー権限を持つメモリマッピングをカーネルが読み込む際に、PAN保護が機能しないのじゃ。メモリ保護は読み取り、書き込み、実行の3つのビットで管理されるけど、OS設計的にはEL0（ユーザーランド）とEL1（カーネル）両方からのアクセスを考慮する必要があるのじゃ。

ロボ子

なるほど。ARMv8のマニュアルでは、PANのチェックは`AArch64.CheckPermission()`で行われるとありますが、「accessible」の定義が曖昧で、「読み取り権限を持つ」と解釈されることが問題なのですね。

博士

その通り！そして、この脆弱性は、OSがexecute-onlyマッピングの作成を許可しているすべてのARMv8.1+チップで悪用できる可能性があるのじゃ。iOSも危ないかもしれないぞ。

ロボ子

もし悪用されると、どのような影響があるのでしょうか？

博士

カーネルが任意のアドレスを間接参照する場合、この脆弱性を利用して、偽のvtableやROPスタックを作成できてしまうのじゃ。恐ろしいのう。

ロボ子

対策としては、どのようなものが考えられますか？

博士

いくつかあるぞ。ARMv8の仕様で`user_r`を`(user_r || perms.xn == '0')`に置き換えるとか、Linuxカーネルみたいにexecute-onlyマッピングを禁止するとかじゃな。あとは、カーネルに入る際に`ttbr0_el1`を無効にして、`copyio`内でのみ復元するとか、AppleのA10チップ以降では、APRR（Apple Proprietary Restriction Register）を使って、execute-onlyメモリを読み取り権限なしとして扱うこともできるのじゃ。

ロボ子

色々な対策があるんですね。でも、根本的にはPAN自体が回避しやすいという問題もあるんですね。

博士

そうじゃ。PANは実際には回避が容易で、execute-onlyメモリとPANの組み合わせによって、他のミティゲーションが破られる可能性もあるのじゃ。ミティゲーションが増えるほど、こういう衝突も増えるじゃろうな。

ロボ子

セキュリティ対策は複雑で、相互作用を考慮する必要があるんですね。勉強になります。

博士

じゃろ？最後に一つ。この脆弱性を見つけた研究者、きっと夜食にパンを食べながらデバッグしてたに違いないのじゃ！

ロボ子

…博士、それはちょっと強引すぎます。