(toppers-users 3442) Re: タスクスタックの状況を確認するためのシステムコール実現の御提案

[SHUKUGUCHI Masahiro]

宿口です。

元もとの返信の意図の１つは

> こんな感じで分けていくと，個々のシステムへの理解は深まりますが，
> 仕様(もしくはガイドライン)としては発散しそうです．「ヤバいことが
> 起きたときに，収束させるにはどのような設計がありうるか」という
> 辺りまでなら，共有できる知識として纏めることも不可能ではないかなと
> 思っています．

といった、これらの議論・提案も無かったのが残念に思ったためです。

過去のメールを見れば、同様の議論があったことは判りますが、すでに
3400を超えるメールを参照することは大変であり、難しいことだと思います。

ゆえに、もう少しリジェクト（とは大げさですが）する理由などがあれば
と思った次第。

Shukuguchi

> こんにちは．
> 
> 分けるとすると，スタックの中が壊されるか，スタックを超えて壊されるか．
> でしょうか．(スタックの中は戻り番地だけというわけではありませんし．)
> 
> -fstack-protector の"ようなもの"とぼかしたのは，ご指摘のとおり
> スタックの外の破壊には気づけないからです．オーバフローへのGCCとしての
> 取り組みとして -fmudflap があったりします．いずれも，TOPPERS でどれだけ
> 使えるかは未知数です．直感ですが．大規模なhackが必要でしょう．
> (ここでは，RTOSではなくコンパイラで対応する実例があることが，重要です．)
> 
> 一方，ハードならオーバフローが検出できるかというと，保護ハードウェアの
> 粒度より小さなメモリ領域のアクセス制御はできませんし．大抵は保護区画を
> 作る資源に限りがあります．スタック内部の破壊にハードが無力かというと
> 必ずしもそうでもないですよね．アラインを間違えた書込みに対して例外を
> 出すアーキテクチャも，割とあります．
> 
> こんな感じで分けていくと，個々のシステムへの理解は深まりますが，
> 仕様(もしくはガイドライン)としては発散しそうです．「ヤバいことが
> 起きたときに，収束させるにはどのような設計がありうるか」という
> 辺りまでなら，共有できる知識として纏めることも不可能ではないかなと
> 思っています．
> 
> 
> 2011年4月29日12:59 T.Fujikura <fujikura ＠ ymail.plala.or.jp>:
> > 藤倉です
> > 　スタックOverflowと戻り番地破壊は分けて考えた方が良いのでは無いかと思
> > う。GCCは戻り番地破壊? ハードに依存はOverflow?
> >
> > (2011/04/29 12:25), Masaki Muranaka wrote:
> >> こんにちは．
> >>
> >> 動的検出の方法は，ハードウェアに頼るか，GCC の -fstack-protector のような
> >> ものを使うか，…いずれにしてもRTOS以外の何かにやらせたほうがよいでしょう．
> >> (手埋めだと網羅確保の問題もありますし)
> >>
> >>
> >> 発生時のカーネルの対応についてですが，POSIXシグナルとの類似性から，
> >> タスク例外処理を使いたくなる気持ちは分かります．
> >> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
> >> 溢れるかもという時に使うのは危険かもしれません．
> >>
> >> ハードウェアの支援がある場合にはCPU例外が発生するでしょう．
> >> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
> >> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
> >> (非タスクコンテキスト内でタスクスタックの残量を見てから
> >> iras_tex を呼ぶ，というパターンはアリでしょう．)
> >>
> >> スタックの残量は，バイト数で得られれば十分ではないでしょうか．
> >> スタック用の配列の先頭番地/サイズとスタックポインタのアドレスは
> >> 現在TOPPERSが対応しているアーキテクチャなら解りますよね．
> >> スタック残量が僅少のときに関数を安全に呼べるかどうかは
> >> アーキテクチャ(もしくはABIが規定するアラインメント)依存ですが，
> >> 類似の問題はメモリプールでも起き得ますので，アプリ開発者の
> >> 解釈に委ねるとしてもよいはずです．
> >>
> >>
> >> で，こういった案をどういうふうにフィードバックするのがよいのか
> >> ということについてですが…
> >>
> >> いずれの案にせよ，タスクスタックを扱う必要がありますので，
> >> SILでカバーするのは難しいのではと思います．
> >> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
> >>
> >> とはいえ，カーネル仕様にできるかというと難しい気もします．
> >> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> >> かなと思います．
> >>
> >>
> >> 2011年4月26日22:59 SHUKUGUCHI Masahiro<shukuguchi ＠ biz.nifty.jp>:
> >>> 宿口です。
> >>>
> >>> 有益なアイデアだと思うのですが、意外と冷たい（？）反応でしたね。
> >>>
> >>> 静的に、タスク設計時のスタック見積りは原則だと思います。
> >>>
> >>> 動的な防護策として、ディスパッチャ、システムサービスのエントリや割込み
> >>> 処理の入口でのスタックチェックがあると良いと思います。これの課題（？）
> >>> は、処理速度とスタックオーバフローを検出した場合の振舞いの定義ですかね。
> >>>
> >>> 処理速度は、コンパイルスイッチ等でスタックチェックの有効・無効を選択
> >>> できれば問題は少なくなりそうですが、それだと、動的にチェックする動機が
> >>> 薄れます。（信用の置けないアプリケーションを搭載するような場合だと特に）
> >>>
> >>> スタックオーバフロー検出時のカーネルの振舞いは、μITRON仕様の範囲では決
> >>> めようが無いと思いますが、タスク例外処理の起動あたりが妥当と思います。
> >>> しかし、タスク例外処理の起動はマスクできますし、そもそもタスク例外処理
> >>> ルーチンが定義されていないと意味を成さないですね。
> >>>
> >>> また、カーネルで一意に振舞いを決めたくなりますが、カーネルに過度の機能
> >>> を持たせることの懸念が生じるように思います。
> >>>
> >>> # だんだんネガティブになっていく。。。
> >>>
> >>> 一方、
> >>> タスク観点では、タスク例外処理ルーチンでスタックオーバーフローを検出した
> >>> 場合に状況を知りたくなりますので、その際や、デバッグ時にはスタック状況を
> >>> 確認するインタフェースは有効だと思います。
> >>>
> >>> でも、CPUアーキテクチャに依存しますので、カーネルよりはSILあたりの
> >>> 実装になりますか・・・ スタックの情報以外にカーネル等の資源状況を調査
> >>> できるデバッギングパッケージなるものがあると、うれしいかもしれませんね。
> >>>
> >>> とりとめもなくすみません。
> >>>
> >>> Shukuguchi
> >>>
> >>>> 皆様
> >>>>
> >>>> 先日は多くの有用なアイデアの共有ありがとうございました。
> >>>>
> >>>> TOPPERSとしては今のところ「それはTOPPERSのサービスとして提供するものではない。」という認識に至りました。
> >>>> このような機能については、先日高田先生から御指摘いただいたTECSを使って実装すれば良いのかもしれませんね。
> >>>>
> >>>> 中村晋一郎
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > --
> > //T.Fujikura
> >
> >