アカウント名:
パスワード:
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のマニュアルがミスリードしていた，マニュアルがよろしく無かった，と言われても仕方ない体裁かなと思います．(そしてこれを発見＆報告した人はすごい人だと思います)
かつての386システムプログラミングを知る人には基本的で重要なことで常識だったから(#3406645)や(#3406689)はすぐにピンときたのですというか昔の資料にはMOV SSとデバッグ例外の話はズバリ書いていたと思うが
とはいえ、Intelだけが悪いかというとそうでもなく、大抵の高機能なCPU/マイコンのドキュメントはこんなものです。明文化されているだけマシで、メジャーではないものだとドキュメントにない仕様・不具合が山のようにあります。おかしな挙動を指摘してあげると、忘れたころにドキュメントに追加されている。一定期間でマニュアルを整理すればいいという意見もあるのですが、変更点を差分管理したいという要望もあり、難しいのでしょうね。
「こんなもん」が当たり前のようにまかり通ってるのに呆れ＆ブチ切れケンカしたことある訳だが「ソフト屋はハード様の言うこと聞け」「ざけんなお前のとこのなんか使わんわ」「どうぞお好きに」だったね。日本のドコかまでは書かんが。で、アッチの方と直接やり取りしたらそうでもなくて会話が成立するのね。「すまぬそこ間違ってた」の返答あったとき、これは完全に負けてるなと痛感したわ。
ハード+ソフトのトータルでどうするかが重要という考えが未だに無いのかと。
それは国の問題ではなく、単に運が良かっただけでは？日常的にこういうやり取りしていますが、どこの国でも「それで、何個買ってくれるの？」が基準ですよ。
購入ロットが小さければ、言葉が丁寧かどうかは別として対応してくれません。「すまぬそこ間違ってた」と言いつつ、直さないんですよね。大口の場合は、すぐにレポート作成してきたり、暫定マニュアルを作ってきたりします。開発費を出してる超大口でもなければ、バグの修正まで対応することはないですけどね。最近のプロセスだと1回修正回すだけで10億～なので、よほどのことでないと修正できない。
#3406860は#3407031で関わった時の事でAPI作ってました。試験段階です。
間違いは何であろうとあり得る、けど応対が真逆でしたね。まあ自分は抜けたのですが、Aの問題はAを直すべき（他の方法での回避は別の問題生む）の人なので大丈夫かと。
ドキュメントの品質を超改善(単に正確であるだけでなく理解しやすく)しても中々金にならんからなあ。現実的には利用者が余分に金を出してでも品質を上げる価値はあるものなのだけど、商品としてのインパクトはやっぱり弱いのよね。
ある規格策定に携わった事がある方が、コードや仕様書全て通して正確＆短く＆シンプル＆解釈ブレない表現のポリシー持ちでした。
自分やった奴がそれだったので気に入ってくれたのですが「そういう考え持って実践してる人って珍しいね」でしたなあ。
金にならんというか、ドキュメントの品質を保つのは一種の才能なんだよ時間が掛けてもダメなドキュメントしか書けないやつは書けない更に言うと、客先に出すドキュメントは一種の契約書で、正確であることが求められる誤解を招くような書き方するとそれはそれで揉めるんで簡易に考えると理解しやすくても複雑に書かざる得ない部分もある
いや個人の才能に依存するのは金を掛けてない典型例でしょ。
それ自体が儲かるプロジェクトなら人員と制作体制揃えてその為のシステムやツールも準備してユーザーのフィードバックにも応えていける。ドキュメントのクオリティを上げると利益が上がる計算なら当然投資した方が儲かる事になる。このてのドキュメントの大変更が掛けられないのはその編集人員と編集後のレビューやチェックにコストを割けない(割く価値がないと見なされてる)から。コストの問題がクリアできるなら詳細仕様と入門者向け概要を両方メンテする事だってできる。それが利益を生むのならね。
数年ぶりにこのネタをかけるけど、Vmwareで仮想基盤環境を構築しその上にゲストＯＳを複数搭載し稼働させたさい、特にリソース不足でもないのに一つのゲストＯＳの挙動がきっかけでホストＯＳも一緒に停止すること稀にないですか？
それはこのバグのせいです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
これは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で仮想基盤環境を構築しその上にゲストＯＳを
複数搭載し稼働させたさい、特にリソース不足でもないのに一つのゲストＯＳの挙動が
きっかけでホストＯＳも一緒に停止すること稀にないですか？
それはこのバグのせいです