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

[b-free: 2113] Re: Manifesto英語版少 し修正。



古い発言への res です。

-Aki.




Takanori Hayashi wrote:
> 
> 林です。横入りします(^_^;)。細かいアーキテクチャの話は
> 見えないので基本的なことだけ。
> 
> In message <35F3A23B.844BACAF@bridgew.edu>
>    "[b-free: 2055] Re: Manifesto英語版少し修正。"
>    "Hideaki Suzuki <h1suzuki@bridgew.edu>" wrote:
> h1suzuki> 分けることの利点は、なんと言っても、app が周辺核や外殻に影響しにくい点だと思い
> h1suzuki> ます。不利な点は、ring 間遷移での overhead ですが、どのくらいの cost がかかる
> h1suzuki> ものなのでしょう?
> 
> マイクロカーネル・アーキテクチャを取る場合はマネージャは
> アプリケーションとは異なるプロセスで走るので、カーネルに
> よって相互に保護されます。リングによる保護は不要です。
> リング遷移のオーバーヘッドはカーネルコールに比べてコスト
> が掛かるわけではないのでそれは問題にはなりません。問題は
> リング機構を持たない(RISCなどの)CPUへの移植に支障が出る
> ことです。

なるほど、

 Overhead は問題ではない。
 移植性には懸念がある。
 Kernel だけ保護しておけば、それ以上は必要ない。(micro-kernel だから)

ということですね。


> 上述の通りマイクロカーネルにリングは不要なんです。リング
> を使うのはBTRON1のようにアプリケーションのコンテキストで
> 走るマネージャがある場合です。
> # BTRON1のマネージャはリング1を使います。

なるほど、これは、app の影響で、manager のもつ property の整合性に問題が
でないようにするためですね。



で、少し考えてみたのですが、micro-kernel では、kernel により process or
task としての保護が効いているという事ですよね。
でも、それって、user applications も、同じ level で走っているわけですよ
ね。
では、manager を悪意のある process が殺したりできるのでしょうか?
Ring level をもとに、そういうことを禁止するのは良い方法といえるでしょう
か?
# たとえば、自分より内側の ring の task は殺せないとか。

もしくは、例えば、network のために「認証 manager」みたいなものを今後
B-free が取り込んだとして、それが管理している機密情報を、ほかの user app
が不当な手段を使って、crack する事が可能でしょうか? それを、ring によ
る保護で、そういった情報への access を禁止する事は、どれくらい意味がある
と考えられるでしょうか?(ring を使用しない<普通の app と同じ level の
process>で認証 manager を作ったときとの危険性、すなわち paging での保護
とはどのくらい違うのでしょう?)

また、B-free にも多くの bug は予想されるでしょうが、そういう bug を駆使
して System を crack しようとしたときに、ring 機構というのはどれぐらい、
有効な物なのでしょうか?



うーむ。
でも、これって、CPU (特に i386)の ring 機構と言うより、ring 状の保護機
構全般の話なのかなぁ。
Software で emulation しちゃえば良いだけの話?



-Aki.


ps. 質問ばかりしてるな、、、。(^_^;;;