複数のOSやハイパーバイザで脆弱性、CPUの予期しない挙動に対する解釈を誤ったのが原因？ 37
ストーリー by hylom
CPUのドキュメントは難しい 部門より
CPUのドキュメントは難しい 部門より
複数のOSやスーパーバイザで、IntelおよびAMDのx86系プロセッサが備えるデバッグ例外処理を適切に処理していないという問題が発見された。これを悪用することでプログラムから本来アクセスできないメモリ領域にアクセスしたり、本来は実行する権限の無い操作を実行できる可能性があるようだ（ZDNet Japan、JVNVU#98401336、VU#631579）。
MOV SSおよびPOS SS命令の実行時にデバッグ例外が発生し、かつMOV SSやPOS SS命令の後に実行される命令が3より高い特権レベルの処理に制御を移すものだった場合に、デバック例外が3より高い特権レベルで実行されるという。その結果、MOV SSやPOS SS命令が予期しない振る舞いを起こす可能性があるという。
そして、複数のOSでこのような予期しない振る舞いが考慮されていないという。これは、ドキュメントやこれらの命令の使い方に対する説明が不明瞭であることが理由だと推測されている。
これはIntelのドキュメントが悪い (スコア:5, 興味深い)
OSを作る人は Intel が公開しているCPUの仕様書，つまりドキュメントを読みます
そのドキュメントはpdf形式で https://software.intel.com/en-us/articles/intel-sdm [intel.com] あたりでIntelが無料で公開しています．
pdf は Vol.1 から始まり，Vol. 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 4 と延々と続いていて，しかもそれぞれのpdfが数百ページあります．全体を通して読んで理解するのは大変な代物です．
今回の脆弱性に関連する説明は Vol. 3A に記載されています．Vol.3Aは460ページあります．長いです．そして今回の脆弱性の原因となった挙動は
- 72ページ目の割り込みフラグの話
- 193ページ目のタスク切替時の割り込みマスク（スタックレジスタのアトミック処理）の話
とに分断されて記載されていました．
私は脆弱性のニュースを知って，それからマニュアルを眺めたのですぐに状況が把握できましたが，
これはIntelのマニュアルがミスリードしていた，マニュアルがよろしく無かった，と言われても仕方ない体裁かなと思います．(そしてこれを発見＆報告した人はすごい人だと思います)
Re:これはIntelのドキュメントが悪い (スコア:2, 参考になる)
かつての386システムプログラミングを知る人には基本的で重要なことで常識だったから
(#3406645)や(#3406689)はすぐにピンときたのです
というか昔の資料にはMOV SSとデバッグ例外の話はズバリ書いていたと思うが
Re: (スコア:0)
とはいえ、Intelだけが悪いかというとそうでもなく、大抵の高機能なCPU/マイコンのドキュメントはこんなものです。
明文化されているだけマシで、メジャーではないものだとドキュメントにない仕様・不具合が山のようにあります。
おかしな挙動を指摘してあげると、忘れたころにドキュメントに追加されている。
一定期間でマニュアルを整理すればいいという意見もあるのですが、変更点を差分管理したいという要望もあり、難しいのでしょうね。
Re:これはIntelのドキュメントが悪い (スコア:1)
「こんなもん」が当たり前のようにまかり通ってるのに呆れ＆ブチ切れケンカしたことある訳だが
「ソフト屋はハード様の言うこと聞け」
「ざけんなお前のとこのなんか使わんわ」
「どうぞお好きに」
だったね。日本のドコかまでは書かんが。
で、アッチの方と直接やり取りしたらそうでもなくて会話が成立するのね。
「すまぬそこ間違ってた」
の返答あったとき、これは完全に負けてるなと痛感したわ。
ハード+ソフトのトータルでどうするかが重要という考えが未だに無いのかと。
Re: (スコア:0)
それは国の問題ではなく、単に運が良かっただけでは？
日常的にこういうやり取りしていますが、どこの国でも「それで、何個買ってくれるの？」が基準ですよ。
購入ロットが小さければ、言葉が丁寧かどうかは別として対応してくれません。
「すまぬそこ間違ってた」と言いつつ、直さないんですよね。
大口の場合は、すぐにレポート作成してきたり、暫定マニュアルを作ってきたりします。
開発費を出してる超大口でもなければ、バグの修正まで対応することはないですけどね。
最近のプロセスだと1回修正回すだけで10億～なので、よほどのことでないと修正できない。
Re: (スコア:0)
#3406860は#3407031で関わった時の事でAPI作ってました。試験段階です。
間違いは何であろうとあり得る、けど応対が真逆でしたね。
まあ自分は抜けたのですが、Aの問題はAを直すべき（他の方法での回避は別の問題生む）の人なので大丈夫かと。
Re: (スコア:0)
ドキュメントの品質を超改善(単に正確であるだけでなく理解しやすく)しても中々金にならんからなあ。
現実的には利用者が余分に金を出してでも品質を上げる価値はあるものなのだけど、
商品としてのインパクトはやっぱり弱いのよね。
Re:これはIntelのドキュメントが悪い (スコア:1)
ある規格策定に携わった事がある方が、コードや仕様書全て通して正確＆短く＆シンプル＆解釈ブレない表現のポリシー持ちでした。
自分やった奴がそれだったので気に入ってくれたのですが「そういう考え持って実践してる人って珍しいね」でしたなあ。
Re: (スコア:0)
金にならんというか、ドキュメントの品質を保つのは一種の才能なんだよ
時間が掛けてもダメなドキュメントしか書けないやつは書けない
更に言うと、客先に出すドキュメントは一種の契約書で、正確であることが求められる
誤解を招くような書き方するとそれはそれで揉めるんで
簡易に考えると理解しやすくても複雑に書かざる得ない部分もある
Re: (スコア:0)
いや個人の才能に依存するのは金を掛けてない典型例でしょ。
それ自体が儲かるプロジェクトなら人員と制作体制揃えて
その為のシステムやツールも準備してユーザーのフィードバックにも応えていける。
ドキュメントのクオリティを上げると利益が上がる計算なら当然投資した方が儲かる事になる。
このてのドキュメントの大変更が掛けられないのはその編集人員と編集後のレビューやチェックにコストを割けない(割く価値がないと見なされてる)から。
コストの問題がクリアできるなら詳細仕様と入門者向け概要を両方メンテする事だってできる。それが利益を生むのならね。
Re: (スコア:0)
数年ぶりにこのネタをかけるけど、Vmwareで仮想基盤環境を構築しその上にゲストＯＳを
複数搭載し稼働させたさい、特にリソース不足でもないのに一つのゲストＯＳの挙動が
きっかけでホストＯＳも一緒に停止すること稀にないですか？
それはこのバグのせいです
うーん (スコア:2)
スタックがどうなっているのか、マッタクわからない。
昔から (スコア:0)
ドキュメントに書いてない事や曖昧な所は叩いてみるのがアレゲ精神。
ドキュメントに書かれていても信用せずに叩いてみるのもアレゲ精神。
ドキュメントのせいでOSのほうの使い方がどうこうではなく、適当に叩いたぐらいで
セキュリティ機能をバイパス出来るようなCPUなのが悪いんじゃないの???
Re: (スコア:0)
WindowsもMacもLinuxもだっていうんだから、
現時点ではドキュメントも、CPUも悪いとしか思えないですね。
# なぜ、vmwareだけ逃れられたのか・・・
Re: (スコア:0)
vmwareではなく、ESXiでしたね。失礼。
Re: (スコア:0)
なぜってそりゃ読み間違えなかっただけだろう
Re: (スコア:0)
作り始めの時に割り込みベクタあたりから逆アセンブルして「よそと同じだからいいや」的に実装し、問題が起こらないからそのまま継承・・・ってのはありがちかも。
で時折こういう部分にこだわる人が担当するときっちり実装てのはありそう。
＃そういうこだわる人は得てして「金にならん余計な仕事する」と批判が多かったりするけど
Re: (スコア:0)
おっと CVE-2012-0217 の悪口はそこまでだ
DOS 時代にデバッガ作っていた世代には既知の話だが (スコア:0)
仮想 386 モードでデバッガ作ったり使ったりしていた世代はまだ現役だと思うけど。
どこかで技術伝承に失敗したか。
まぁフラットメモリモデルに移行した時点で、セグメントレジスタ書き換えをすることが、まず無くなった。ってこと何だろうけど。
それとも、単一の（不完全な）ソースがあって、それを Windows / macOS / Linux でコピペしていた？
Re: (スコア:0)
VMのスーパーバイザなんて、元をたどればそれほど種類があるわけではあるまい。
x86系だと2系統か3系統しかなかろう。
特にMicrosoftは確実に外部から買ってきたものがベースだしな。
Re:DOS 時代にデバッガ作っていた世代には既知の話だが (スコア:1)
innotekとかConnectixが2006年前後に作りこんだ不具合が波及しているんじゃないか？
たぶんVMwareは別系統で同じミスをしたと推測できる。
Re: (スコア:0)
スタックの設定は、セグメントレジスタSSとスタックポインタESPへの設定の2命令が不可分なのですな
それでSSの設定だけが特別扱いされているのだが、存じなかったと
Re: (スコア:0)
DOS 時代はメモリ保護なんて気にしてないことがほとんどだから特権昇格とか気にしなさそうだけど、
仮想86モードで16bitコードを実行しているのにデバッグ割り込みで意図せず32bit実行モードに移っちゃうとかがあるのかな？
だとしたらそれはツライ。ソースコードに注釈いれて赤線ひいときたい。
# 仮想386 って何ぞやって思ったけど、デバッガの文脈から DOSエクステンダじゃなく仮想86モニタの話かなー、と。
# 勘違いしてたら解説もらえるとうれしい
BSD族 (スコア:0)
WinMac主要LinuxFreeBSDがアウトの中OpenBSDとNetBSDがセーフなのは「ころしてでもセキュアにする」「極力ハードウェア依存しない」というポリシーの成果なのだろうか
Re:BSD族 (スコア:2, おもしろおかしい)
> ころしてでもセキュアにする
健康のためなら死んでもいい。的精神ですね。
Re:BSD族 (スコア:1)
不健康に生き永らえるくらいならむしろ死ぬ、はそれはそれで真っ当な思想のような気もする。
Re: (スコア:0)
PC-UNIX系ではNetBSDが好きな自分としてはほっこりします
MINIX3はどうなんだろう？
昔読んだ話だが (スコア:0)
OSの開発者はCPUにはバグが多くて仕様書どおりには動かないことを知っているとか記憶がある
（だからこっそりマイクロコードで修正してるとか）
Re:昔読んだ話だが (スコア:1)
CPUのステッピングごとに違うエラッタがあったりするのでOSのコードを見るとエラッタ対応というコメントのついた
コードが山盛り見つかりますよ
Re: (スコア:0)
熟練の開発者は社内ライブラリにはバグが多くて仕様書通りには動かないことを知っているとか記憶がある
（だからこっそりマイクロコードで修正したりしなかったり、しないほうが多いか？）
#言いたかっただけです
Re:昔読んだ話だが (スコア:1)
gccのバク見つけたとか嬉しそうに書いてる奴いるけどそんなに珍しくもないよね。
ちょっと新しい機能をつつくと結構出てくる。
Re: (スコア:0)
GCCに夢を食われた人そんなに多いのか。
Re: (スコア:0)
ジャイアントコードで修正する必要がないだけマシだな
大幅な変更で機能がうっかり変わったりするし
Re: (スコア:0)
命令セットのバグなんてめったにありません（そもそもバグがあったら客が作ったプログラムがまともに動かない）
バグが多いのはCPUコアの部分ではなくて、プロセッサ内蔵のペリフェラル関係の動作
かつて某有名メーカーの著名プロセッサ内蔵ペリフェラルのとある動作モードのバグが発売開始後数年たって発覚・マスク変更になったことがある
＃何年もたってそのようやくその特殊な動作モードを使う客が出てきたからバグが見つかったというオチ
Re: (スコア:0)
ん？
本件は仕様書には一応書かれていたけどわかりにくかった、って話ですよね。
そして (スコア:0)
POS SSって違うんじゃね。
Re:そして (スコア:1)
POS SSって違うんじゃね。
POP SSと他の記事は書いているのに。アセンブラ経験ないのかな。