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

[b-free: 1434] Re: Memory Protection





多分、アドレス間違いだと思うので、フォワードします。


---
B-Free プロジェクト実行中! 詳細はこの Web ページへ
(http://www.sccs.chukyo-u.ac.jp/B-Free) 


内藤隆一 (rnaitoh@st.rim.or.jp)

---- Begin included message ----
Ryuichi Naitoh wrote:

> >  1.program によって、使う data/code の量が大きく
> >    違うのに、どうやって、適当な address 空間の
> >    配分を決められるか。>loading 時に決められ無くもないけど。
> 
> これは、問題ないんじゃないかなぁ。普通 code 領域が大きくなることはない
> ことを考えると、code 領域を data 領域の前に置いておけばいいような気が
> します。
> code 領域と data 領域が連続していれば無駄もないし。GCC でコンパイルす
> ると、自動的にそういう配置になりますね。

すると、固定 address はどちらにしろ使わないと言うことですね。
loading の時に、data の先頭を決定して、relocation で修正すると。

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

heap と data を一緒にするのですか?
問題ないですか?
LMB と一緒にすると言うことですよね?
僕は、別にした方がいいと思いますが。
僕は、data 領域は大きさ固定にして、可変の heap/stack と分けた方が、分か
り易い気がしますが。

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


> stack については、たしかに他の領域とぶつからないかは問題です。ただ、
> 普通は、プロセス空間の最初と最後の方に配置してしまって済ませていますね。
> スタック領域が 1G を越えるようなことになれば問題が発生が発生するだろう
> けど、その前にメモリ不足になってしまうでしょう(今のところは)。
> 
> 問題といっても、暴走とかいう問題より、スタックオーバーフローのような形
> で出てくると思います。

うーむ。一般保護例外(386 int 13)でしょうかね。もしくは、stack check を
push/pop の際に常にやる必要がありますね。
というか、非常に早く進む技術を前に、こういう不安要因は除いた方がいいので
は?


> 
> >  3.data を実行しようとした場合に、どう protection を掛けるか。
> 
> これは、page の access privilege で指定できます。
> 実行ファイルのフォーマットで code と data は分けて配置してあるから、
> OS が見分けるのは簡単ですし(というか、OS が見分けやすいようにそうして
> あるんですが)。

code と SMB を同等の方法で確保できれば、memory 管理が楽に行きそうな感じ
がするのですが。

で、SMB の akey って、segment name と同等じゃないかって。

 
> 逆に segment を使ってしまうと、たとえば、関数のポインタを使いたいとき
> などに困りませんか?
> code セグメントとオフセットの両方の値がないと関数のポインタは表現でき
> ないわけで、ポインタの形式が問題になってきます。

code から、data へ移行することはないのですから、near で良いでしょう。
386 の場合なら、CSを一度設定しておけば、offset のみでの処理となりま
す。
絶対 address と違うところは、offset 0 から初めて良いと言うところではない
でしょうか。
絶対 address だと、segment の配置により、offset の開始 address が0以外
の固定値になる可能性がありますね。


> > あと、386 arch. の話で、もう一つの利点(僕が書いたやつ)は、flat model
> > で process を走らせる場合に programmer は 386 の仕様(限界?)のために、
> > code も data も stak も heap も、ぜーんぶ、4Gの address 空間に押し込ま
> > なければいけません(と言うほど一般人の用途には狭くはないけど)。で、も
> > し、seg. 一つに code とかって割り振れば、code/data/stack/heap それぞれ
> > が、4Gまで使えます。その辺が、若干の追加の良い点かな。
> 
> うーん、資源の問題をいうならば、386 アーキテクチャだとセグメント数に限
> 界があることを考慮しないといけないのでは?
> 
>  4G を越えるプログラムはそんなに多くはないと思いますが、セグメントの方
> は、プロセス毎に必ず 4 つ必要なわけで、セグメントが足りなくなる方が問
> 題としては現われやすいと思います。

うむ、これは問題ですねぇ。
でも、GDT/LDT それぞれに、8192 (13 bits)まで segment descriptor がとれる
の事を考えると、4Gを越える program の方が頻度は高い気もしますが。4G
を越える program は使うところでは、使うのでは?

 
> あとは、まぁ、コンパイラがセグメントを意識するようになっていないので、
> C 言語でセグメントを扱うためには、コンパイラ自身の改造が必要になってし
> まいますね(GCC が大きなプログラムだということを考えると、これが一番問
> 題かも)。

確かに、これが最大の問題かも。
でも、86用の GNU はあるでしょ?

 http://www.delorie.com/djgpp/

とか。
っていうか、segment を扱えるようにするのが、面倒なんか。
うーむ。startup code の書き換えだけじゃぁ、すみませんかねぇ。


> 
> 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


-Aki.
---- End included message ----