はじめに
昨年（2012年）の6月13日に、IntelのCPUで動作する一部のOS、仮想化ソフトウェアなどでセキュリティ上の問題が発生するというニュースが流れました。この件は普通にパッチが各社、各開発元から供給されて、いつものように対応がとられました。
今回はこの脆弱性そのものではなく、脆弱性の元になったIntelのCPUにおけるSYSRET命令とソフトウェアの開発にまつわる話題について書いてみたいと思います。
脆弱性のアナウンス情報（抜粋）
- Intel CPU で動作する 64bit OS や仮想化環境に権限昇格の脆弱性 – Japan Vulnerability Notes
- Windows カーネルの脆弱性により、特権が昇格される (2711167) – マイクロソフト TechNet オンライン
- The Intel SYSRET privilege escalation – blog.xen.org – Community Blog
いったい何が起こったのか？
この件で脆弱性が発現したソフトウェアは、IntelのCPUにおけるSYSRET命令の動作に対しての理解が足りていなかったことにより、特定の前提条件を暗黙のうちに想定していました。これにより、細工をしたスタックフレームを作成し、RCXレジスターに対してnon-canonicalアドレスを入れてSYSRETを実行すると特権の昇格を起こしえるという問題が発生しました。
なぜIntelのCPUでだけ問題が発生したのか？
それはこのSYSRETの実装がAMDの実装と異なっていたためです。そのためにIntelの実装では問題のあるSYSRET命令の使い方をしてしまっていました。
それはIntelのCPUのバグなのではないか？
実際にこのIntelのCPUにおけるSYSRETの仕様については不具合だとするサイトも見かけます。※1しかし、ことこの件に関してはソフトウェア側の問題だと思います。というのも、IntelのCPUにおけるSYSRET命令は、Intelが公開している開発者向けの資料に掲載されている通りの動作をしているからです。あとはこの仕様書を見て、この命令を使うか使わないかなどを検討するのはソフトウェアの実装者に任せられた問題です。
実際に今回の脆弱性が報告されたことにより、仕様書に記載された内容から何が起こっているかを理解し、各開発元は対応するパッチをリリースすることができました。これによって脆弱性は除去できたのです。
なぜアナウンスの中にLinuxがないの？
Linuxにもこの脆弱性が存在しました。ただし、2012年に見つかって対応したのではなく、さらに6年前の2006年に対応をしています。この時に情報が広まっていれば2012年になってから一斉に問題化することはなかったことでしょう。
まとめ
このようにCPUの命令には潜在的に危険なものが含まれていることがあります。※2仕様書に書いてある動作をよく確認し、その動作に問題がないか検討する必要があることを知らせてくれた事例だと思います。仕様書に記載された仕様通りの動作なのですから、CPUの不具合であるというのは誤った見解です。
ただ…、私個人としては、IntelはこのSYSRETの仕様を変更した方がいいと思います。短期的には効果はあまりないでしょうが、5年後、10年後もIntel 64が使われているであろうことを考えれば仕様を変更する価値があると思います。変更によって互換性に与えるダメージがあるものでもないと思います。いかがでしょうか？
- 例えばOSDev.org（OS Development Wiki）の
SYSENTER項目には以下の記述があります：All Intel CPUs to date (2013) have a silicon bug when executing the SYSRET instruction.
（さかきけい意訳：SYSRETの実行に伴うバグを2013年現在、IntelのすべてのCPUが持っている） - つまり、Intelのこの
SYSRET命令は危険な地雷です。