一般発表E3「オペレーティングシステム」 [開催会場] Ｅ会場 [参加人数] 40 〜 45人程度 [開催時間] 7/25 13:30 〜 15:04 会場の様子：組込用OSへの関心がOSを利用した開発の効率化に集まっている感を受けた。資源の再利用性、デバッグ時やシステムの堅牢さを高める保護等がキーになっていた。質疑応答では，新しい提案に対する現行システムの変更方法などが中心となっていた。全体を通して開発者として視点からみたOS技術への関心の高さが伺える内容であった。以下，発表内容： ============================================================================== 「組込みマイクロカーネルOSの高速化」久住憲嗣九州大学システム情報科学府中西恒夫奈良先端科学技術大学大学院情報科学研究科福田晃九州大学システム情報科学研究員 --[概要]---------------------------------------------------------------------- マイクロカーネルOS構成の組込用OS「Lambda」の実装を行った。また、プロセス間通信を関数呼び出しの形式変換可能な物を変換すること（モノリシック化と呼ぶ）を中心にマイクロカーネルの欠点である性能の低下を抑止する事を一つの指標とし、評価を行った。 --[発表]---------------------------------------------------------------------- １．現在の組込み用OSの背景とLambda OS 組込み機器の多様化・複雑化しており、ソフトウェアの生産性・再利用性の向上が必要不可欠となりつつある。しかしながら、現在のRTOSの大部分は実効性能やメモリ効率を優先して実装されている。OSそのものの開発効率化などはあまり考えられていないようだ。それにたいしてLamda OSというマイクロカーネルのOSを実装した。２．以下の点を主眼においてLambda OSの実装を行った。・生産性の向上（再利用性を高める）・性能をなるべく落とさない３．コンフィギュアラブルであることハードウェア依存部分を細かくモジュールに分けて実装する。新しいデバイスが提供されたときでもできるだけ小さい実装で移植できるようにしている。リターゲッタブル OSと呼んでいる。将来的にはハードウェア依存部分の自動生成を視野に入れていきたい。４．生産性の向上（構想段階）保護を有効に活用したいと考えている・メモリ空間・ CPU時間・各種ハードウェア資源保護を簡単に設定できるような枠組みを提供したい。５．マイクロカーネル構成による性能低下の防止組込みシステムの特徴を考えてみると、「出荷後のソフト構成を変更できない」「比較的プロセス構造などが変化しにくい」などがある。現在マイクロカーネル構成でしているがこの構成だと保護をかけやすい。しかし必要のないところでは、この構成がオーバヘッドになってしまっている。そこで、実装時にはマクロカーネルで構成し、出荷時は、モノリシックカーネル構成に自動変換できないか？という動機を得た。６．モノリシック化の基本方針プロセス間通信の内、冗長な物を削除する。その手法としてRPC を関数コールに変更する。これをモノリシック化と呼ぶ。ミドルウェアを含めパフォーマンスの効率化が期待できる７．環境とLamda OSのアーキテクチャ SH3評価ボード IA32（PC/AT）対象とするアーキテクチャとしてはMMUをもつようなものを考えている。 a. Lambdaの構成・マイクロカーネル・メモリ管理サーバ・ APIサーバ以上で構成される。たとえばμITRONサーバなど設置できる。提供する機能は以下の通り。 b. 管理機構・スレッド管理機構・割込み管理機構・タイマ管理機構（タイマドライバ）・メモリ管理機構・プロセス間通信： Lambdaインターフェイスジェネレータ（LIG） [スレッド/プロセス管理機構] マイクロカーネルの中に単純なスケジューラを実装する。これは置き換えが可能となっている。複雑なスケジューリングポリシが必要な場合は外部にスケジューリングサーバを置き、このサーバと協調して新たなポリシを提供できる。 [プロセス間通信] ・同期式・バッファリング無し・送受信を同時に扱うモードを持つコピー、マッピング等、モノリシック化による高速化だけでなく。マイクロカーネルによるパフォーマンスの低下をできるだけ防止する基本的な工夫を行う。 [割り込み管理機構] ハードウェアから割り込みが来るとハードウェア割り込みハンドラというカーネルの中の機能を呼び出す。例外・タイマ割り込みではないのならSendInterrupt モジュールに飛び、登録されているドライバに通信する。特に応答性が必要な場合は、ハードウェア割り込みハンドラに直接、割り込みハンドラを実装することもできる [インターフェイスジェネレータ（LIG）] Remote Procedure Call（RPC）を簡単に利用できるようにする。通信相手に応じて通信方法を変えることにより効率化をはかる。８．LIGによるモノリシック化クライアントとサーバが同一モジュールにいる場合（同じアドレス空間にいる場合）関数呼び出しを行い、異なるプロセスにいる場合は、RPCを行う。 ┌ Thread 1 ───────┐ │　　　　　　　　　　　　│　　┌ Thread 2 ───────┐ │┌───┐　┌───┐　│　　│　┌───┐　┌───┐│ ││　ク　│⇔│スタブ│⇔ (RPC ) ⇔│スタブ│⇔│サーバ││ ││　ラ　│　└───┘　│　　│　└───┘　└───┘│ ││　イ　│　　　　　　　│　　└────────────┘ ││　ア　│　　　　　　　└──────────┐ ││　ン　│　┌───┐　┌───┐　┌───┐│ ││　ト　│⇔│スタブ│⇔│スタブ│⇔│サーバ││ │└───┘　└───┘↑└───┘　└───┘│ │　　　　　　　　(関数呼び出し)　　　　　　　　│ └───────────────────────┘ イメージ図：サーバスタブとクライアントスタブイメージ図のように、同一空間で在れば関数呼び出しに置き換える。９．予備評価機能呼び出し手段 | 所要時間(μsec) ----------------------+---------------- RPC | 50 モノリシック化RPC | 1.1 関数呼び出し | 0.7 以上のように高速化の確認ができた。１０．まとめ実装時にマイクロカーネル構成し、出荷時にモノリシック化する手法の提案を行ったまた、組込み用のマイクロカーネルの実装を行い、その上でモノリシック化の評価を行った。 --[質疑応答]------------------------------------------------------------------ Q. 実装の時にRPCを使って実装、うまくいった後、普通の関数呼び出しに変えることによってタイミングが大きく変わってしまうと思うのですがタイミングが重要で検証後タイミングを変更されたくないときはどうすればいいのですか？（組込みでは完成してしまえば、タイミングを変更したくない事が多い） A. 実装して問題がないならRPCのまま使ってもいいし、性能が欲しい部分では関数呼び出しに変える事が可能。 Q. 割込みの配送する部分に関することですが、この構造だとドライバに任せたのち割込みコントローラ側で割込みフラグが落ちないような場合、登録されたドライバから戻ると、フラグが落ちていないので立て続けに割込みが発生してしまうと思うのですが、どう対策していますか？ A. 基本的にメモリマップドI/Oで在れば，ドライバ側の空間にマップしてやってドライバでたたけるようにする。カーネル内に書いてしまえばそのような問題は無くなる。つまり、普通のI/Oであればカーネルに機能を作り込むしかないかもしれない。 Q. 割込みを高レベルで抽象化すると割込みの配送時にやはりこの問題に引っかかってしまうと思うのですが？ A. カーネル内部にハンドラを実装にしないとやはり発生すると思う。実装を進めてみないとどのような構造になるかわからないが、今はアドレス空間が同じなのでこの問題は発生していない。将来的には、こういった問題も対処していきたい。 ============================================================================== 「μITRON仕様へのメモリ保護の導入」高田広彰豊橋技術科学大学 --[概要]---------------------------------------------------------------------- 保護機構の必要性とμITRONに対する保護機能拡張に関して・仕様の方針・保護の対象とアイデア・保護機能に対するハードウェアのサポート以上の点から現在の構想を発表する。 --[発表]---------------------------------------------------------------------- 背景組込み市場の急速な成長分野に置いて、競争力の観点から開発期間が短縮される傾向にある。このことはソフトのクオリティの低下をまねき。本来許されないバグの発生を招く。また、外部からダウンロードしたプログラムを実行するというような従来に無かった応用が求められるようになってきている。このような場合は、セキュリティの確保が重要となってくる。そこで、OS側からのアプローチとして、OSに保護機構を入れるという事が考えられる。１．OSの持つ保護機能の目的保護機能の目的としては、障害が他の正常なシステムに波及を防ぐ事を中心的に考えている。保護の種類をあげる。・メモリ保護機構・ OSオブジェクトのアクセス保護機構・時間分割される資源の保護機能発表では上二つを中心にすすめてゆく。一方、現在のRTOSの保護機能について考えてゆくと 1) オーバヘッドの大きさ 2) 小規模なソフトが多く高い信頼性を確保することが比較的容易だった 3) 外からプログラムをダウンロードされることなど無かった以上の理由により、従来のRTOSは保護機構を持たない物が多かった。２．保護の目的を分類現在検討している保護機能について、保護を目的別に分類してみた。 1) デバッグ支援のための保護機能 2) 信頼性向上のための保護機能 3) セキュリティ確保のための保護機能 1)によりデバッグ時に原因の特定が容易になる。また2)により信頼性用件の異なるモジュールを混在が可能になり開発が容易になる。3)は後からプログラムなどをダウンロードできる環境に必要。以上のようにRTOSの保護機能は、目的によって異なるスペックを持つといえる。上記 1)・2)については、時折発生するような単純な不具合を検出できればよいのに対して、 3)は、故意に攻撃を受けるため厳密な保護が必要となる。このように、目的によって異なるスペックになる。すべて別々のスペックを作成するよりμITRON の特徴である弱い標準化を行うことで、サブセット化を容易にする。以上の事柄から容易にサブセットかできる保護機能を目指す。３．仕様の方針・完全な保護を提供する。これを元に実装毎にサブセット化を行える仕様を目指す・オーバヘッドをできる限り小さくする。どうしても大きなオーバヘッドが発生する場合は、該当する保護機能を取り外せるようにする・できる限り単純な仕様を目指す・多重メモリ空間はサポートしない４．保護の概念アクセス主体(Subject)とアクセス対象(object)の概念を導入する。アクセス主体からアクセス対象へアクセスする場合、「アクセス許可パターン」をアクセス対象に設定して保護する。アクセス許可パターンとは、UNIXのファイルにおけるパーミッションに似た概念である。一方で、全てのアクセス対象に対して「アクセス許可パターン」設定するのは困難であるため、同一のアクセス許可パターンを持つ物を「保護ドメイン」でグループ化する。アクセス許可パターンは保護ドメインに対してかける事により一括して保護の制御が行える。 [機能の追加] ・保護ドメインを作成する機能・メモリ領域をカーネルに認識させる機能・アクセス許可パターンを設定する機能・アクセス許可パターンを動的に変更する機能・不正なアクセスを検出する機能 [異なる保護ドメイン間の通信] ・コピーなしのメッセージ通信・メモリページに対するドメインの付け替え機能（ページリマッピング） [オーバヘッドの低減] ・メモリ変換を行わない・静的な判定を活用メモリ変換に対してどの程度低減できるかはハードウェアのサポートによって変わる。５．ハードウェアによるサポート典型的にはメモリ保護に対してMMUがある。 [MMUのタイプ] ・CISCタイプMMU CISCタイプのプロセッサがとっている方法（一部RISCもある）論理空間毎にハードウェアのページテーブルの形式が決められている。ハードウェアでページテーブルを検索してアドレス変換してくれるタイプ。結果はTLBにキャッシュされる。 > ページテーブルは保護ドメイン毎に用意する必要がある。工夫の余地はあまりない・RISCタイプMMU MIPS、SH3等で見られるMMU。ハードウェアはTLBのみ持つ。ページテーブルを検索してTLBを設定する処理はソフトで行うタイプ。TLBの構造はソフトウェアで自由に決めることができる。メモリ変換が不要だとページテーブルの構造の中に変換先のアドレスを持つ必要が無くなる。ページテーブルは小さくできる。また必要なメモリのサイズは静的に定められるなら、最適化ができる。 > 工夫の余地有り。実装して評価したい。・MPU ARMに搭載されているハードウェア。メモリ変換を行わずメモリプロテクションのみ提供してくれるおもしろいハード。 > 細かい内容は省略するが高速であり、また最適化の余地がある。しかし、柔軟性がないといえる。６．まとめ μITRON 仕様に導入を検討しているメモリとカーネルオブジェクトに対するアクセス保護機能の目的を紹介し，概略を説明した。今仕様の検討中である。ご意見コメントをいただければ反映できる。10月頃までには骨子を決定して今年度内には仕様をだしたいそれと同時に評価実装をして、最適化などは研究テーマとしてもやっていきたい。ハードウェアサポートとの関係： μITRONの実行しやすいようなハードサポート機能。 MMUでもMPUでもないものが設計されると嬉しいとおもう。 --[質疑応答]------------------------------------------------------------------ Q. この方法では、メイルボックスなどは変えなくては行けないと思うのですが， ITRONとして新しく仕様を作るのですか？ A. ver4に対するメモリ保護オプション仕様としてだしたい。 Q. 例えば最初のデバッグに対する保護に対して，保護を達成したいと思っても既存のシステムでは問題があると思います。では，メイルボックスなどを使っている場合は、どうするのですか？ A. ちゃんと保護をかけようとすると厳密には変えないといけないかもしれない、でも弱い標準化の観点からは、変えないと言う実装も可能だと思う。 μITRONのメイルボックスはユーザが送信した領域の先頭数バイトを使ってキューを作る。その領域をユーザが壊すとカーネルがパニックする。今は保護がないからいいけど，このままだと保護したことにならない。 Q. 既存のメイルボックスは保護ドメイン内でしか使えないと言うことですか？ A. 保護ドメイン内でも使えない。 APIはほとんど保存するつもりだ、仕様上、変わるところは余り無いかもしれない。バッファのサイズを指定するなどの変更があるとおもう。アプリケーションはかなり持ってくることが出来ると思う Q. 現実的には、メイルボックスは、ドメイン内では使えるけどドメインにまたがると使えないと言うことですか？ A. ドメイン内で使うだけでもカーネルを無限ループに落とせる。 Q. 管理領域だけは別領域に持っていくことで逃げられる？ A. 保護ドメイン間では，メッセージを共有メモリ領域に置けば大丈夫。あとはユーザの責任。 Q. メモリ保護の視点とは少し違う質問ですが、キャッシュに関して質問があります。ドメインにわけた中にもキャッシュ内容を載せたい領域，載せたくない領域が出てくると思う。プロセッサによってかなり変わってしまうところではあるが、コントロールができると嬉しいと思うのですが？ A. 面白くまた難しい問題。実装する方法はあると思う。ただ、キャッシュはプロセッサ依存が大きいので標準化は少し難しいと思う。製品の実装と仕様の標準化はわけて考えています。 Q. 1つのオブジェクトが2つ以上のドメインに所属できるのですか？ A. 1つのドメインだけに所属できる。 Q. もし２つ以上のドメインに属することができるので在れば、先ほどのメイルのアクセスの話については、メイルボックスをメイル専用の保護ドメインに入れて置いて、メイルにアクセスする専用のタスクを共有ドメインとメイルにアクセスしたいタスクのドメインに属するようにしておき、アクセス用のタスク経由でアクセスすれば、メイルの先頭領域を壊さずにアクセスできるのでは？ A. 先ほどは説明できませんでしたが、保護ドメイン内のアクセスパターンはデフォルトであって、後に変更することは可能です。ですから、資源は便宜上どこかのドメインに属しているだけです。このばあい、アクセスしてくるタスクへのアクセスパターンを設定することで対処できると思います。 ============================================================================== 「Linux On ITRON の概要」金田一勉エルミックシステム --[概要]---------------------------------------------------------------------- 二つのOSを組み合わせたHybrid OSとして、Linux＆ITRONを紹介する。名前の通りITRON上でLinuxを動かすものである。 --[発表]---------------------------------------------------------------------- １．はじめにそれぞれのOSの利点など Linux ・オープンソース・サーバ,PCで採用・組込み分野に置いても採用が検討されているしかし組込み分野で利用するにはリアルタイム性が弱い点が欠点としてあげられる。 ITRON ・オープンスペック・日本でデファクト・安価なハードウェアでリアルタイム性の実現・日本の企業内では数多くの資産があるしかし、多くの資産も他のOSへの移行が困難。一方でソフトウェア部品が充実しているとは言えない点が欠点として上げられる。 LinuxとITRONを1つのプロセッサで動かすことで欠点を補完するという動機。・数多くのLinuxのアプリを利用・ITRONリアルタイム性が利用できる・ITRONの資源を利用ができる・LinuxとITRONの２つのハードが必要なところを同時に扱うことによってハードウェア原価を削減できる以上のメリットが考えられる。２．emblix 日本における組込みLinuxの普及活動を行っている団体。・開発環境WG ・リアルタイムWG ・ハイブリッドアーキテクチャWG 以上のWGを持っている。今、ハイブリッドアーキテクチャWGでこのLinux On ITRONを扱っている。３．Linux On ITRONの方針３つの点をあげる a. ・Linuxカーネル本体への修正は行わない・CPUに依存する処理程度の修正にとどめる理由としては、・Linuxバージョンに非依存にしたい・ベンダ依存を省きたい b. ・ITRONのシステムリアルタイム性を保つ理由は ITRONのシステムを流用してもリアルタイム性を失うと意味がない。 c. ・基本となる動作の提案とユーザインターフェイスの仕様をWGで策定理由は実装によって仕組みは変わってもユーザの使い勝手を変化させない４．処理の優先順位高 ITRON側の割込み処理 ↑ ITRON側カーネル・スケジューラ ITRON側タスク Linux側割込み処理 ↓ Linux側カーネルボトムハーフスケジューラ Linux側プロセス低このような構造になっているのはITORN側のリアルタイム性を損なわないためである。５．ハイブリッド基本構造 a. LinuxはITRONの最低優先度のタスクとして動作させる。 LinuxはITRONのスケジューラによってスケジューリングされる。 b. ITRONシステムの動作中はLinuxの割込み処理を抑制する ITRONの動作中にLinuxの割り込みを処理するとITRONタスクがLinuxの割り込みによってどんどん遅延されてしまう。リアルタイム性を保つためである。 c. OS間情報交換が行えるような手法を持つ二つのOS間で情報が行えないと、同時に一つのハードで動かせる意味がない。６．割込み制御 ITRONシステムが使用する割込みを割込み制御プログラムに通知する。割り込み制御時に割り込み要因によってITRONの割り込みハンドラもしくは、LinuxのISRを呼び出す要因によってどちらか必要なOSを呼び出すという機構。またITRON動作時はLINUXのISR は呼ばない。 ┌───────┐ │Linuxカーネル │ │割り込み登録 ├─┐ └───────┘ │ ┌───────────┐ │ ┌─────┐ │Linuxデバイスドライバ ├─┤ ┌─┤ ITRON │ │割り込み登録 │ │ │ │割込み登録│ └───────────┘ ↓ ↓ └─────┘ ┌──────────────┬──────────────┐ │ Linux側割込み管理テーブル │ ITRON側割込み管理テーブル │ └──────────────┴──────────────┘ ↑ ↑(優先的に参照) │ ┌─────────┐ │ │ITRON側割込み判定 │ ┌─────────────────────┴─────────┤ │ Linux割込み処理 │ └───────────────────────────────┘ 図：割込み登録処理概念図 [Linux環境] ： [ITRONシステム環境] ┌─────────────┐ ： │Linuxデバイスドライバ │ ： │ ┌────────┐ │ ： ┌──────────┐ │ │Linux割込み処理 │ │ ： │ ITRON割込みハンドラ│ │ └────────┘ │ ： └──────────┘ └──────↑──────┘ ： │ ： ┌──────┴──────┐ ： ┌──────────┐ │割込み調停プログラム │ ： │ 割込みスケジューラ │ └─────────────┘ ： └──────────┘ ：図：Linux側割込み発生時 [Linux環境] ： [ITRONシステム環境] ┌─────────────┐ ： │Linuxデバイスドライバ │ ： │ ┌────────┐ │ ： ┌──────────┐ │ │Linux割込み処理 │ │ ： │ ITRON割込みハンドラ│ │ └────────┘ │ ： └──────────┘ └─────────────┘ ： ↑ ： │ ┌─────────────┐ ： ┌────┴─────┐ │割込み調停プログラム ├───→│ 割込みスケジューラ │ └─────────────┘ ： └──────────┘ ：(Linux割込みマスク、Linuxコンテクスト保存) 図：ITRON側割込み発生時７．OS間インターフェイス二つ方法を考えている。・データをコピーする方法：ストリームを使う・データをコピーしない方法： OS間共有メモリを利用するインターフェイスについては、仕様を策定中である。まとまればEmblixのサイトで公開予定となっている。８．まとめハイブリッド構造の考え方は、ITRON仕様だけに限らないものである。他のOSでも同様に考えることができると思っている。Emblixでは、今後、制作されていく製品の使い勝手をまとめることでユーザの戸惑いを軽減することが最初の目標である。 --[質疑応答]------------------------------------------------------------------ Q. 優先度はITRONタスクが上でLinuxプロセスが下になっています。ユーザはこの設定を変えられませんか？ A. 優先順位についてはいろんなケースが考えられる。紹介したのはあくまで基本のケースと考えてください。 ITRONタスクでもアイドリング時になにかポーリングしたりすることはあり得る。そんなときITRONのアイドルタスクとLinuxプロセスと優先順位が逆転する事などは、十分考えられる。 Q. OS間のインターフェイスは、排他する必要がありますよね？ A. 排他の必要がある。共有メモリを使う場合など必要になる。 Q. ITRON タスク複数を使い、二つ以上のLinuxを1つのシステムに割付けることは可能ですか？ A. 可能だとは思うが、一つのCPUに二つ以上のLinuxシステムでは必要性に疑問符。 Q. Linuxだけだとリアルタイム性はとぼしい紹介されましたが、リアルタイム性を持たせた RT LinuxようなOSなどもある。競合すると思うがそれについてはどう考えているのか？ A. Linux On ITRONの特徴として大量にあるITRONの資産や情報を利用できる。それに対してRT Linuxのような新しく出てきた技術では、まだ機能的に充実していない部分などがある。リアルタイム性については満足できるそうだが、実際にシステムを構築する場合、ITRONプログラマにとって見ても新しい技術を勉強するよりも負担が小さい。これらの観点から、Hybrid OSにメリットはある。 Q. 優先度に関してですがLinuxの割込み処理よりITRONタスクの方が高いのはどういう事ですか？割込みよりタスクの方が優先されていることに違和感があります。 Linux側の割込みは高速性がないことを仮定しているのですか？ A. ITRONを優先することを基本のパターンとしています。 Q. ITRONのタスクより遅くていい割込みというのはどういったものでしょうか？ A. 高速な通信をしないような場合など考えられる。制御では使わずに、遅い通信やユーザインターフェイスなどを考えている。 Q. タスクが実行されるということは、どれだけ待たされるか分からないということですか？ A. ITRON側では事象待ちの処理にしてほしい。いままではポーリングもかなり使われているようだが、できるだけポーリングはやめて事象が発生してから処理を開始するプログラミングのガイドラインがいる。 Q. Linuxの割込みがITRONタスクより優先度が高いと困るような処理は？ A. 特にはないと思う。逆転していてもかまわない。実際そういうケースも考えられる。あくまであれは基本パターン。たとえばITRONの割込み番号とLinuxの割込み番号が同じになってしまうPCIバスなどでは十分考えられる。環境によって変わらざるを得ない。 Q. Linuxが1つのITRONタスクで動いているということは？メモリマネージメントは？ A. Linuxのタスクは1つと限定されているわけではない。複数かもしれない。実装によります。実はMMUや仮想メモリはLinuxが占有している。 ITRONは特権モードで物理メモリ空間上に配置されます。 Comment. Linuxをなるべくさわらない。ITORNの保護とLinuxの仮想空間を共存させようとすると相当改造する必要があるかもしれない。Linuxをそのまま使うのは無理があると思う。マイクロカーネルにするのも手かもしれないが、Linuxをそのまま使うというスタンスからは逸脱してしまう。両方のメモリマネージメントがぶつからないようにすり合せる必要があると思う。もう一つ、割込みに関して。「なぜ割込みよりReal-Timeタスクの方の優先度が高いか？」 Linuxの割込みには長い割込みがある。あと長い割込み割込み禁止がある。仮にカーネルの中で割込み禁止ししたとすると、その間（の優先度）で優先度逆転が起こる。なかなか両立が難しい。 RT Linuxは基本的にLinuxで処理を行い，リアルタイム性が必要な部分だけリアルタイム側に持っていくスタンスなのでうまくいく。 Linux On ITRONは基本的にスタンスが違って、こちらはITRONの資源を有効に使うためにリアルタイム側を優先していて、その他Linux側の資産も利用するというスタンス。こういったところでもRT Linuxとの違いがあり棲み分けが出来ると思う。