「x86でもプロセッサによるバッファオーバーフロー対策」記事へのコメント

要するに

[jim-vrtx (16640)]

欠陥アーキテクチャって事ですね。
欠陥アーキテクチャのCPUを使ったシステム(Windowsに限らず)に
依存しているこの世の中って？？？？

スタックオーバーフローなんて、OS/コンパイラー以前に
システム設計時につぶせるものだと思うのですが...。

^-_^-_-~
救世主はきっといる。

Re:要するに

[Anonymous Coward]

どちらかというと、OSやアプリの欠陥による被害をハードレベルで防止する話だと思いますが。
まぁ、セグメント単位での実行権限制御はあるのに、なぜページ単位では無かったのかとか疑問はありますが。

あと、スタックあふれじゃなくてバッファあふれだと思う。

Re:要するに

[Anonymous Coward]

いつも思うのだが、コードセグメントとスタックセグメントに
重なりがあるように設定するWindowsがタコなだけではないだろうか？

おまけに、x86はセグメントのベースアドレスだけではなく、
セグメントサイズも設定でき

Re:要するに

[tmiura (6268)]

工夫次第ではいろいろ出来るハズだが。

なんですが、 「セグメント管理なんて煩雑なことは嫌」といって その工夫をあえてしないフラットメモリモデルを 採用することにしたのが 今の世の中というかUNIXとWindowsの隆盛なわけです。

Re:要するに

[SteppingWind (2654)]

「セグメント管理なんて煩雑なことは嫌」っていうのは, おそらく8086がまき散らした害毒でしょうね. 本来はセグメント機能によって主記憶の用途管理がちゃんとできるはずだったのですが, 8086上のDOS環境では単純に足りないアドレスをゴマかすための機構に成り下がっちゃいましたからね. 8086の設計ってConcurrent-CP/Mみたいに数10kB単位のプログラムをセグメント管理で複数動かすというものだったんじゃないですかね? そんな時代じゃ, たかだか数MB程度フラットに使わせろってのも切実な願いだったわけで.

Re:要するに

[tmiura (6268)]

あながち8086ばかりでもなくて、上から降りてくる方の動きとしてMulticsの失敗も強烈なトラウマになってるんじゃないかと思うんですよ。いやむしろそっちじゃないかと。

ほら、プログラマにモデルを受け入れさせるとともにOSを供給しなきゃいけないじゃないですか。

ややこしいものを作りたくない背景のもとでUNIXは流行ったし、UNIXが動けばいいやでRISCのアーキテクチャも殆どフラット一色。VAX/VMS辺りは知りませんが、RISCの流れがそうなったってことはミニコンも末期頃にはセグメントが廃れてたんじゃないかと想像したり。 それを見て、何

Re:要するに

[Anonymous Coward]

素人考えですが、セグメントに分けておけば
・コードもデータも0番地から考えておけばいい。
　片方の領域のサイズが変わってもオフセットの変化を気にする
　必要がないから、コンパイラ（リンカの方か？）が楽を出来る。
・データ領域をプログラムと思ってしまうことがない。
　プログラムがバグってコード領域以外にジャンプしても、
　ハードで簡単に検出出来る。
というような利点があると思いますが、どうでしょうか？

> IA64やAMD6

Re:要するに

[Anonymous Coward]

セグメントの概念を使うのとCPUのセグメンテーション機構を使うのとでは全然別じゃないですかね。

セグメントの概念自体はx86とは関係なくUNIXでも普通に使っているんですよ。
普通、プログラムファイルは
　コードセグメント (実行可、読み書き不可)
　定数情報セグメント (読込み可、書込み不可)
　初期化付きデータセグメント (読み書き可)
　初期化なしデータセグメント (読み書き可) ファイル上はサイズ情報のみ
　スタックセグメント (読み書き可) ファイル上はサイズ情報のみ
みたいな構造を持っています。
# MMUの都合で実際にはコードセグメントも読込み可なことも多い

それでこういうセグメントの実装はセグメントサイズをページ境界に整合させればページング機構だけで簡単にできるんです。
x86のようにセグメントをハードウェアで支援してもOS作成者から見れば硬直していて扱いにくいだけになってしまいます。