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

[b-free: 1146] 安全な中間 code の運用



題名を「安全な中間 code の運用」替えました。



◆ bytecode による、App. Chain の、より詳しい説明。

bytecode で、「お回し」即ち「実身の自動加工」を実現すると、Virus の問題
が一番に出てくる。B-free は、何をおいても、BTRON の名に掛けて、「安全な
OS」であって欲しい。


「原則」
 bytecode が、利用者の知らない間に、許可無く、利用者及び System の実身
に対して影響することを禁止する。



決まり1:
 bytecode は App を起動できるが、App に渡せる実身は、bytecode のある実
身(たぶん違う record )と bytecode の生成した実身のみである。

決まり2:
 bytecode は、新しい VM を起動しては成らない。すべての処理は、自分が走
っている VM 内のみで行われる。VM を起動できるのは、(たぶん)実身仮身
Manager のみで、さらに利用者の明示的要求にのみよる。

決まり3:
 App ですら、VM を起動しては成らない。決まり2の通り、VM を起動できるの
は、実身仮身 Manager の内部からのみ、しかも利用者の要求があってのみであ
る。すると、BTRON1 の Event Handling の方法では問題を生じる。これには二
つの解決が考えられる。

1.App が、仮身のopen 起動を掛ける場合。(BTRON1 の拡張)
   仮身の open 起動に付随する VM の起動に当たっては、利用者の要求があ
ったという証明が必要となる。それはたぶん、Event Handling の中で作られ、
その証明は偽装、再利用などが行われる事が出来ない物とする。偽装防止の一つ
の方法としては、生成された Event を、「書き込み不可」の属性をつけて、O
S側の Memory Address に保持しておくことである。Memory Address を調べれ
ば、模造された物か判別がつく。再利用防止に対しては、Event を常に消費され
る物とし、 App は得られた Event に対して、必ず、対応をすることである。対
応とは、「Manager に送り返す」か「App 内で消費」の二つである。一つの
Event に対して対応をしない場合は、次の Event を受け取れないとすれば、再
利用を防ぐことが出来る。 ただし、この場合、個別の App が応答しなくなる
bug を生みやすい。

2.実身仮身 Manager が、仮身の open 起動を掛ける場合。
   これは、B-free が、高度に OOP/高機能化された場合。
   Window を Object とみなし、OSの管理下に置く。App は、開くことの
出来る仮身を、Window Object に登録するのみ。Event Manager が適切な
Manager (例えば、実身仮身 Manager)に直接、Event を送る。App は、すでに
所定の Manager に送られてしまっている Event の "copy" を受け取って、必要
なら対応する処理(登録や登録抹消など)を行う。Manager 間の情報伝達が直接
行われるので、Security の関わるところは OS の安全性が増す。 ただし、
Manager が十分に賢くなくてはいけないので、OSの肥大化を生みかねない。



BTRON1 及び手段1の Event Handling が、

  OS 核 → App → Manager

だったのに対し、手段2では、

  OS 核 → Manager → App(事後連絡) → Manager

となる。手段2が可能なのは、OSが資源(window など)の十分な情報を持って
いて、自分で、十分な判断が出来ることが前提。




◆ Timer と App Chain の連携。

決まり4:
 bytecode に対する世界の制限に対する一つとして、VM は "boot schedule"
実身(もっと良い名前がないかなぁ)には書き込めないとする。

決まり5:
 "boot schedule" から起動された実身は、利用者からの起動と同等に扱われ
る。


 - Aki.

追伸。もうそろそろ、宿題しよっと。:-)