(toppers-users 3683) Re: 保護拡張仕様(μITRON4.0/PX)の疑問点とその対応アイデア

[Masaki Muranaka]

高橋さん，みなさま:
こんばんは．

> 動的生成の必要性自身がなければいらない技術かもしれません。それはそうかもしれない
> と思います。

要らない(もしくはユーザがいない)技術を仕様に盛り込むリスクを，仕様を考える際は常に感じなければ
いけないですよね．

一般論として，検証工数がべらぼうにかかるシステムでは，キホンはユーザドリブンにならざるを得ません．
美しいから可能だからという理由で仕様を弄るのは，なかなか難しいのではと思います．
// いまやTOPPERSの中の人ではありませんので，個別事案でどういう判断になるかは知りませんが．


> ただオーバーヘッドに関しては、動的生成そのもののオーバヘッドから考えると、単純に

保護ドメインのID化は，ゼロオーバヘッドになりえますか?

たとえば [a]cre_dom なるサービスコールがあったとして，その処理時間は相応に時間ががかかるかも
しれません．そして，何度も呼ばれるサービスコールではないので，システムの寿命におけるこれら
サービスコールの実行時間の割合はたかが知れているのは確かに言えそうです．
しかし，各サービスコールでは，評価時にそのIDが有効であること(生成されていて削除されていないこと)
を確かめる必要がありますね．おそらく割り込み禁止区間内にです．
これも大したことがないかどうか，それはもちろんアプリ次第です．

最優先で護るべきリソースが"時間"であるはずの RTOS で，そのオーバヘッドを許すに足るだけのメリットを
享受できるアプリが具体的に存在するならば，動的も考えるべきかもしれませんね．


> これは少々乱暴なご意見かと思います。

plan9のセキュリティモデルが乱暴なのか，組込みシステムへの適用が乱暴なのか，どちら方面からのご指摘でしょうか?

私も実は心配性なので，ときどき鍵は多ければ多いほどよいと思ったりはします．
ですが分厚いリングプロテクションの Mutlcis が失敗の母で root/user だけの Unix が生まれたという人もいます．
もちろん，揺り戻しもありますね．
明らかにノーガードなのは論外ですが，保護がどうあるべきかというのは，時代とか使えるリソースとかで決まるので，
どれが乱暴とか乱暴でないとか一概に言えるものではないかなとも思います．


2011年11月4日16:08 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:
> お世話になります。コメントありがとうございます。
>
> On Fri, 4 Nov 2011 14:53:07 +0900
> Masaki Muranaka <monamour ＠ monaka.org> wrote:
>
>> 高橋さん，高田先生，みなさま:
>>
>> 議論進んだところで，ぐるっと引き戻してしまうかもしれないですけれど…．
>>
>> > また、これは、現状は、動的生成が仕様にも実装にもサポート外であるので静的APIの
>> > 範囲によって保護違反と思われる定義は人的に防ぐことが可能なため大きな問題でもな
>> > いと思います。
>> > ただ、動的生成においてもアクセス保護のついてこの問題を回避できる方法があれば
>> > それに越したことはないと思っています。
>>
>> PX型 (≒新世代の保護拡張) のカーネルで，動的生成が求められるかという点を
>> まず検討せねばならないのではないでしょうか．
>> 仕様として美しいに越したことはないのですが，セキュリティチェックは，
>> ほぼ全てのサービスコールでオーバヘッドになりますので．
>
> 動的生成の必要性自身がなければいらない技術かもしれません。それはそうかもしれない
> と思います。
> ただオーバーヘッドに関しては、動的生成そのもののオーバヘッドから考えると、単純に
> カーネルドメインか否かをチェックする方法とアクセス許可ベクタから判断するものが
> 影響するほどのものではないと考えています。構造体からC言語ベースなら1判断かと思います。
> 余談になりますが、PX型においては、HRPの実装においてデータ構造的にタスクスイッチや
> prb_mem()など保護ドメインの切り替えにおいてオーバーヘッドが結構あるように思っています。
> 詳しく見ておりませんが、メモリオブジェクトの管理情報は、ATA_MEMで与えられた構造体の集合になって
> いるようですので、タスクスイッチなどでも保護ドメイン変更時は、該当保護ドメインの情報を集めてハードウエアの
> メモリ管理テーブルに並べる必要があるからと思うからです。実際には上手い方法でされて
> いるのであれば、間違った見解かもしれません。
> いずれにせよ、オーバヘッドがあるからないからというものではなく、オーバーヘッドとのトレードオフだと
> 思います。妥当な時間で処理が可能であれば利用するメリットのほうが高くなると考えています。
>
>>
>> 個人的には，「どんなに優れた認証システムを作っても，認証サーバの
>> コンソールに悪人を置いたら終わり」と見切ったPlan9の考え方を倣って，
>> 悪意の存在しうるタスクは物理的にOSやプロセッサを分けるくらいの姿勢が
>> 妥当な気がしたりしています．
>>
>
> これは少々乱暴なご意見かと思います。
> また、個人的なことであったことでたとえ話をします。
> 子供にマウンテンバイクを購入しました。普通自転車を買うと簡単な鍵はついていますが、マウンテンバイク
> は、構造的についていないのが普通ですと、店員が言うのです。
> 新品の自転車は、ほぼ間違いなく鍵無なら持っていかれます。新品で程度のいいものなら2個つけるのが普通です。
> ただ2個つけたところで、ワイヤーカットする器具を使えばとられるから、同じという意見と同じように
> 思います。
> Linux関連でもセキュア機能が搭載されてきています。いわゆる今のLinuxは普通のセキュリティが搭載されて
> いると考えています。セキュア機能がまた十分でなかったころのものも権限による管理はされています。
> つまり、「認証サーバのコンソールに悪人を置いたら終わり」という観点からすると、どちらも同じ、
> つまり鍵1個も2個も同じだという意見のように思います。
>
> 動的生成を含めたものと考えれば、素のPXの仕様は鍵無（マウンテンバイク）、拡張サービスコールを考えた場合に鍵1個のものに該当、
> 普通のセキュリティポリシーである鍵2個に相当する機能を持たせるほうがいいのではないかという
> ことを考えています。
>
> ご意見いただければ幸いです。
>
> ---
> アライブビジョンソフトウエア株式会社
> 高橋和浩
> 673-0005兵庫県明石市小久保2-2-7幹線ビル4F
> Email:takahashi_kazuhiro ＠ nifty.com
> http://homepage3.nifty.com/ALVS/
>
>