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

[Masaki Muranaka]

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

> 個人的には，検証工数の増分はさほどではない気はしています(って書くと検証チームに刺殺されるかも)けれど，
> 先のメールで長めに書いたとおり，ほぼ全てのサービスコールに係ってくる時間的なオーバヘッドは
> どうなのかなというのは気になります．

一番最初の高橋さんの提案は"カーネルオブジェクト"ですね．その後"動的生成"という話が挟まったので
ID管理化するというふうに誤読していましたが，アクセス許可ベクタの管理はオブジェクト番号で行うと
するならば，大多数のサービスコールで，現状のコードに対するオーバヘッドはゼロですね．
(cfgやacre_系サービスコールには手が入って微々たるオーバヘッドはありそうですが，無視できそうですね)
高橋さん，このような理解でよいですか．


2011年11月4日22:35 Masaki Muranaka <monamour ＠ monaka.org>:
> 高橋さん，みなさま:
> こんばんは．
>
> 発散させてしまったようなので，少し絞ります．
> 大事なところを無駄に絞っているようならご指摘ください．
>
>> こういう前提で考えた場合にどうでしょうか？　という話をしているわけです。
>> そういう前提が成り立たなければ話にならないのは、最初から認めています。
>> さらにこうすればこのようにできるね。　といわれて、強迫観念的に作らなければならないという考えなのでしょうか。
>> すぐに検証に時間がかかるとかいう話になってきたりします。
>
> ええと，全て仮定の話という前提に立つとしても，その仮定の副作用として，
> 「それどう検証するの」「時間性能どうなるの」という意見が出るという仮定は容易にできますよね．
> 「検証のことなんて考えなくても良い」という仮定ももちろん(言葉の上では)できますけれど，
> しかしそんなカーネルを PX/HRP/HRP2 のユーザが使いたがると仮定できるものでしょうか．
> または「検証の工数なんて現実的な範囲に収まるよ」という仮定が成り立つとかでもよいのですが…．
> 莫大な潜在ユーザが発現するので検証コストなど相対的にケシ粒になるという仮定も
> ありかもしれません．単に技術の問題ではない評価が必要になるかもしれませんけれども．
>
> 個人的には，検証工数の増分はさほどではない気はしています(って書くと検証チームに刺殺されるかも)けれど，
> 先のメールで長めに書いたとおり，ほぼ全てのサービスコールに係ってくる時間的なオーバヘッドは
> どうなのかなというのは気になります．
> // ただでさえ割り込み禁止区間が長いと陰口叩かれているTOPPERSですから．;-)
>
>
> 実装への強迫観念はありません．ただ，一般論として実装のニーズが無い仕様は不自然ですし，ましてや
> μITRON仕様とは違ってTOPPERSの仕様書は実装仕様を謳っています．
> 仕様の拡張を仮定するなら，リリースまでに起こる系の全て，とは言わないまでも有り得そうな物事は
> 仮定しないと片手落ちだろうとは思います．
>
>
>> 動的生成＆保護機能カーネルは世の中にあるかないか調べたのでしょうか？
>
> 調べるも何も，静的生成のほうが圧倒的に少ないと思いますが…．
> POSIX準拠の少なからずのカーネルはその枠に入りますね．
> Javaなどの言語レベルで保護が入るもの書かれたカーネル群も概ね入りますし．
> ご近所だと T-Kernel もですよね．
>
>
> 2011年11月4日21:03 kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>:
>> こんばんは、
>>
>>
>> On Fri, 4 Nov 2011 19:56:54 +0900
>> Masaki Muranaka <monamour ＠ monaka.org> wrote:
>>
>>> 高橋さん，みなさま:
>>> こんばんは．
>>>
>>> > 動的生成の必要性自身がなければいらない技術かもしれません。それはそうかもしれない
>>> > と思います。
>>>
>>> 要らない(もしくはユーザがいない)技術を仕様に盛り込むリスクを，仕様を考える際は常に感じなければ
>>> いけないですよね．
>>>
>>> 一般論として，検証工数がべらぼうにかかるシステムでは，キホンはユーザドリブンにならざるを得ません．
>>> 美しいから可能だからという理由で仕様を弄るのは，なかなか難しいのではと思います．
>>> // いまやTOPPERSの中の人ではありませんので，個別事案でどういう判断になるかは知りませんが．
>>>
>>>
>>
>> こういう前提で考えた場合にどうでしょうか？　という話をしているわけです。
>> そういう前提が成り立たなければ話にならないのは、最初から認めています。
>> さらにこうすればこのようにできるね。　といわれて、強迫観念的に作らなければならないという考えなのでしょうか。
>> すぐに検証に時間がかかるとかいう話になってきたりします。
>> つい先日、村中さんの話の中でコメントしたことですが、できないという結論を導くのはできるという結論をだすより難しい
>> ということです。時間やコストを踏まえてもそうだと思います。無料のようなコストでとか今すぐにという状況ではできないのは
>> 間違いありませんが。
>>
>> まず可能性を考える。次に実現性を考えます。今まで可能性がどうかという話をしているかと思います。
>> ところがいきなり実現性の話を持ち出す場合があります。これもひとつのディベートかもしれませんが
>> お互いに建設的結論を導き出す方法とは違う方法のように思います。
>>
>>
>> ユーザーニーズはどこにあるのかというのは、私にしても、少なくともTOPPERSプロジェクトとしてもあまり得意な分野では
>> ないように思います。ちょっといいすぎかもしれませんが、TOPPERSにしてもユーザーニーズに沿ったものにする取り組みもされてきて
>> いると思いますが、ユーザーニーズについて語れるほど情報はここにはないと思います。
>> このユーザーニーズの話、つまり動的生成＆保護ドメインカーネルオブジェクトについてのニーズの有無は、水掛論のように
>> 思います。
>> ただ、ちょっと自分が卑怯ないいわけを最後にするとすれば、動的生成＆保護機能カーネルは世の中にあるかないか調べたのでしょうか？
>>
>>
>>> > ただオーバーヘッドに関しては、動的生成そのもののオーバヘッドから考えると、単純に
>>>
>>> 保護ドメインのID化は，ゼロオーバヘッドになりえますか?
>>>
>>> たとえば [a]cre_dom なるサービスコールがあったとして，その処理時間は相応に時間ががかかるかも
>>> しれません．そして，何度も呼ばれるサービスコールではないので，システムの寿命におけるこれら
>>> サービスコールの実行時間の割合はたかが知れているのは確かに言えそうです．
>>> しかし，各サービスコールでは，評価時にそのIDが有効であること(生成されていて削除されていないこと)
>>> を確かめる必要がありますね．おそらく割り込み禁止区間内にです．
>>> これも大したことがないかどうか，それはもちろんアプリ次第です．
>>>
>>> 最優先で護るべきリソースが"時間"であるはずの RTOS で，そのオーバヘッドを許すに足るだけのメリットを
>>> 享受できるアプリが具体的に存在するならば，動的も考えるべきかもしれませんね．
>>>
>>
>> この部分もアプリがなければ必要ないという話と検証にかかるコストのことですね。
>> ということは、アプリに必要性が認められ、さらに検証可能（適切なコストでの）であればいくらかの
>> 有効性は認めるということなんでしょうね。
>>
>>>享受できるアプリが具体的に存在するか
>> これも先日、村中さんに回答いただいたものです。SafeGなら該当するでしょう。ただ、TrustZoneというハードウエア依存かと
>> 思います。保護機能もハードウエア依存なので、ハンデは同じかもしれません。
>>
>>
>>
>>>
>>> > これは少々乱暴なご意見かと思います。
>>>
>>> plan9のセキュリティモデルが乱暴なのか，組込みシステムへの適用が乱暴なのか，どちら方面からのご指摘でしょうか?
>>
>>
>>>「どんなに優れた認証システムを作っても，認証サーバのコンソールに悪人を置いたら終わり」と見切ったPlan9
>> 見切ったということはPlan9以外の認証サーバーに悪人おいたらおわりのものはまったくだめという話です。
>> これが乱暴以外のなにものでもないと思いませんか。
>>
>>
>>
>>>
>>> 私も実は心配性なので，ときどき鍵は多ければ多いほどよいと思ったりはします．
>>> ですが分厚いリングプロテクションの Mutlcis が失敗の母で root/user だけの Unix が生まれたという人もいます．
>>> もちろん，揺り戻しもありますね．
>>> 明らかにノーガードなのは論外ですが，保護がどうあるべきかというのは，時代とか使えるリソースとかで決まるので，
>>> どれが乱暴とか乱暴でないとか一概に言えるものではないかなとも思います．
>>>
>>
>> 少し誤解されているようで残念ですね。
>> 書いた内容が不適切で誤解を招くことはあると思いますが、疑問点に関して確認したうえで相手を尊重してご意見したいと
>> 思っていますし、議論する相手についてもそれを期待したいですね。
>>
>> --
>> kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>
>>
>>
>
>