[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1444] Re: Memory Protection




隆一です。



> > >  2.stack/heap などは大きさが変化するが、他の data
> > >    や code などを address 空間で浸食してしまう可能性はないか。
> > 
> > heap 領域については、data 領域が大きくなると考えれば、data 領域そのも
> > のと考えていいんじゃないかな。
> 
> heap と data を一緒にするのですか?
> 問題ないですか?

Linux などの UNIX 系の OS はそうやっています。
知るかぎり大きな問題はないみたいですが。アクセス権はデータとヒープで変
わらないので、プロテクトの問題もないですし。


> heap を data に取り込むというのはどう言うことでしょうか。

私の考えているメモリモデルは、UNIX 系ですので、鈴木さんの考えているモ
デルとは違うかもしれません。

取り込む(?) というか、データとヒープをひとつづきの領域として扱うとい
うことです。で、stack は分離した領域になります。なぜかというと、スタッ
クの成長方向がヒープと違うからです。

LMB は、、、どうでしょうね?
むしろ、B-Free では、単純にヒープ領域はひとつにまとめてしまった方がい
いような気もしますが。


> > stack については、たしかに他の領域とぶつからないかは問題です。ただ、
> > 問題といっても、暴走とかいう問題より、スタックオーバーフローのような形
> > で出てくると思います。
> 
> うーむ。一般保護例外(386 int 13)でしょうかね。もしくは、stack check を
> push/pop の際に常にやる必要がありますね。

i386 だったら、ページフォールトでしょう :-)
# stack check については、「今のところ」論外でしょう。


それに、最初からスタック領域を物理メモリに割り付けるのならともかく、
スタックの成長にしたがって物理メモリを割り付けるならば、同じ仕組みは必
要です。ページフォールトが起きたときに、スタック領域の時には物理メモリ
を割り付け、それ以外の領域のときにはプログラムエラーに分けることになり
ます。

ところで、スタックとデータの領域を別セグメントにするのは問題がないです
か?  データ領域の値をスタックにもっていくことはよくあると思いますが、
そのたびにセグメントを切り替えるのは繁雑では?(時間的にも処理的にも)


> というか、非常に早く進む技術を前に、こういう不安要因は除いた方がいいので
> は?

これについては、意味がわかりません。

将来の技術の変化を考えると、64bit アドレス空間になることはまず確実です。
64bit アドレス空間上では、スタック領域をコード/データ領域と別々の空間
に入れることによる問題はむしろ減るでしょう。



> > 
> > >  3.data を実行しようとした場合に、どう protection を掛けるか。
> > 
> > これは、page の access privilege で指定できます。
> > 実行ファイルのフォーマットで code と data は分けて配置してあるから、
> > OS が見分けるのは簡単ですし(というか、OS が見分けやすいようにそうして
> > あるんですが)。
> 
> code と SMB を同等の方法で確保できれば、memory 管理が楽に行きそうな感じ
> がするのですが。
> 
> で、SMB の akey って、segment name と同等じゃないかって。

共有メモリのアクセスは特別の API を使うことになるので、セグメントと一
緒にする利点は特にないと思います(API 内でチェックすれば済むから)。

セグメントを扱うとなると、メモリ管理が複雑になりそうです。


> > 逆に segment を使ってしまうと、たとえば、関数のポインタを使いたいとき
> > などに困りませんか?
> > code セグメントとオフセットの両方の値がないと関数のポインタは表現でき
> > ないわけで、ポインタの形式が問題になってきます。
> 
> code から、data へ移行することはないのですから、near で良いでしょう。
> 386 の場合なら、CSを一度設定しておけば、offset のみでの処理となりま
> す。

複数セグメントを使う場合(特に 4G を越えるプログラムを考慮すると)とか、
動的ライブラリの処理とかいろいろありそうです。

鈴木さんは、動的ライブラリをロードするとき、別セグメントを使うことを考
えていますか?


> 絶対 address と違うところは、offset 0 から初めて良いと言うところではない
> でしょうか。
> 絶対 address だと、segment の配置により、offset の開始 address が0以外
> の固定値になる可能性がありますね。

えーと、この利点がわかりません。別にオフセットが 0 から始まらなくても
問題はないと思いますが。オフセットが 0 から始まることが、そんなに良い
ものなんでしょうか?

プログラムを C 言語のような高級言語で書くことを考えると、値としてアド
レスを意識することはほとんどないと思うのですが。


> >  4G を越えるプログラムはそんなに多くはないと思いますが、セグメントの方
> > は、プロセス毎に必ず 4 つ必要なわけで、セグメントが足りなくなる方が問
> > 題としては現われやすいと思います。
> 
> うむ、これは問題ですねぇ。
> でも、GDT/LDT それぞれに、8192 (13 bits)まで segment descriptor がとれる
> の事を考えると、4Gを越える program の方が頻度は高い気もしますが。4G
> を越える program は使うところでは、使うのでは?

うん、使われると思います。
しかし、4G バイト以上のメモリ空間を必要とするアプリケーションに対し、
それを解決するのはセグメントではなく 64bit アドレスでしょう。

コード/データなどの領域を別セグメントにしたとしても、各セグメントの最
大サイズは、それぞれ 4G バイトにすぎません。これでは、すべてをひっくる
めて 4G バイトの場合にくらべてそれほどの利点にならず、焼け石に水でしょ
う。

セグメントの利点というのは、アドレス空間のサイズの拡張とは別のところに
あると思いますけど。。。


p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
b----------------------------------------------------------------------d