ネットワークOSの必要条件

　以上のことから，次世代の組み込み装置を作るための基本的な機能として，以下のような要件が定義できる．

● ネットワークに接続できること

　いうまでもなく当然の話である．パソコンやそれに類するたぐいの装置を使用しなければネットワークに接続できない機器や，あるいはスタンドアロンで動作することを前提にしている機器は，その制御にいかに高性能なCPUを使用していたとしても，いかに大容量のメモリを搭載していたとしても，OSにBSDを使うなどということはしないほうがよい．

　そういうたぐいの機器向けのRTOSはほかにたくさんあるのでそちらを使うか，あるいはジェネリックなOSを使ったことによるオーバヘッドを避けるためにすべてを作ってしまうかどちらかの方法をおすすめしたい．

● 最低限自分の身を守れるセキュリティをもつこと

　ネットワークの世界においては，いつどこに悪意をもったユーザーが潜んでいるかわからない．現在のネットワークはある程度信用できるセグメントを信用できないセグメントからファイアウォールによって守るというインテグレーションがなされている場合が多い．しかし，もはやパケットがファイアウォールの内側からのものであるからといって，これを全面的に信頼するのは危険である．

　そのパケットはコンピュータワームに感染したコンピュータからのシステムの破壊を目的とした物かもしれないし，ファイアウォールの中から外に向かって掘られたトンネルを通って来たパケットかもしれない．あるいは，ここまで疑うときりがないのだが，内部の人間の意図的なアタックという可能性すらないとはいえないのである．

　このようなことから，組み込み向けネットワークデバイスには，最低でも以下のようなセキュリティ機能が必要になる．

1）パケットフィルタ

　特定用途向け機器のネットワークセキュリティを向上させるための第一の手段としては，「必要のないパケットは受け取らない」に限る．できれば物理層からアプリケーション層に至るまでの各段階でパケットの有効性，必要性をチェックし，壊れたパケットや必要のないパケットはアプリケーションが受け取る前に破棄できる仕組みが必要だ．一般的なネットワークプロトコルスタックの実装においては，アプリケーション層ではこれらのパケットは，ストリームやデータグラムとしてしか認識できないため，パケットレベルでのフィルタリングはOSの仕事となる．一方でフィルタリングアルゴリズムはアプリケーションによりフレキシブルに変更可能でなくてはならないので，OSはフィルタリングアルゴリズムを変更できるAPIないしはパラメータをもっている必要がある．

2）認証メカニズム

　ルータやアクセスポイントハードウェア，あるいはインテリジェントスイッチなどのネットワークインフラとして使われているシステム以外のネットワークに接続可能な装置で，きちんとした認証メカニズムを備えているものはごくごく少ない．これは先にも書いたが，今現在のネットワーク自体がファイアウォールによって保護され，不正なユーザーはそのネットワークに入れないという大きな前提に基づいているためである．

　しかし，将来のことを考えるといつまでもファイアウォールに頼っているわけにはいかない．IPv6による家庭内LANが当然となったとき，現在のIPv4＋NAT＋ファイアウォールといったセキュリティのトポロジがそのまま通用するのかどうか．IPv6の実装は完全なEnd to Endの通信をめざしている．この世界においてネットワークに接続される機器はすべて自分の身は自分で守る必要がある．

　そのためには，自分自身がネットワークに対して提供している機能を，誰に，あるいはどの機器に対して提供するのかを判断する必要がある．このためには今自分の提供しようとしているサービスを利用しようとしているのは誰なのか，あるいはネットワーク上のどの装置なのかを正しく認証できなければならない．

　さらに製品出荷後のファームウェアアップデートをリモートシステムから行うようなシチュエーションを考えるならば，この認証機能はいくつかの特権レベルごとに行われなければならない．たとえば以下のような具合だ．

・装置が提供するサービスを受けられるための認証
・装置の設定を変更する権利を得るための認証
・装置のファームウェアの書き換えを行える認証

3）リソースプロテクション

　ネットワークに接続された装置においては，

?たとえ実行中のあるプログラムが侵入者によって侵されても，同時に実行中のほかのプログラムの動作には影響を与えない

という機能が必須となる．もし，この機能がなければ，いかにOS自体を堅牢に作ったとしても，ある一つのアプリケーションタスクからシステム全体を侵される危険に身をさらすことになる．

　これを防ぐために必要となる機能がメモリのプロテクション機能である．

Column2
 ソフトウェアのパフォーマンス

　ソフトウェアを設計する場合に考えなければいけない要素の一つとして，一般性とパフォーマンスのトレードオフという問題がある．

　プリエンプション付きのマルチタスクカーネル上に実装されたアプリケーションは一般性をもつが，ある特定のシステムを最高の状態に仕上げるためには，時として我慢のできないオーバヘッドをもつことがある．たとえば，あるシステムにおいてシリアルポートへのアクセスは，必ず一つのタスクによって行われることがわかっているとき，そのポートへのアクセスにいちいち排他制御をかけるのはオーバヘッド以外の何者でもない．

　一方で，一般性をもたなくてはならないOSにしてみれば，「正しく動き続ける」ことがもっとも優先度の高い事象であり，そういったOSから見れば，「ほかのタスクは使わないから」と排他制御もかけずにポートを使用しているタスクは潜在的なバグをもっていると考えざるをえない．結果，OSとしてはポートは使う前にロックし，使い終わったらロックを解除するという手順を踏まなくてはならない．これは，明らかにオーバヘッドをともない，結果としてパフォーマンスに悪影響を与えることだろう．

　このような例はほかにもたくさんあるが，一般的にそのソフトウェアが最大限にチューニングされている状態において，一般性をもつべく記述されたソフトウェアは，それ専用に記述されたソフトウェアよりパフォーマンスが落ちるということである．このことはソフトウェアの開発時だけでなく，ハードウェアの開発時にもぜひ頭に入れておきたいことである．実験室でスペシフィックなハードウェア向けに1から10まで書き起こされたソフトウェアが叩き出したパフォーマンス（メモリサイズだったり，速度的な性能だったり）は，最終製品を考えたオーバヘッドをもった環境では往々にして出ないのである．

● ネットワークからシステムのアップグレードが行えること

　コンピュータネットワークはすでにできあがってしまった技術ではない．現在まだ進行形で発展している技術である．そのため，設計時には考えもしなかったようなパケットやプロトコルがネットワーク上を「スタンダード」として飛び回ることがありうる．

　もちろん，そのプロトコルなどが開発される前に販売された製品が，新しく開発されたパケットやプロトコルに対応しなければいけない必然性はまったくない注2が，それによって装置の動作がおかしくなるという事態は避ける必要がある．1台何千万もする高価な装置であれば，あるいは出荷台数そのものが少ない装置であれば，不具合の解消のために人が出向いて現地でソフトウェアの修正作業を行うこともできるかもしれない．あるいは，1台数千円から数万円のコンシューマ機器であれば，その時点でその製品はEnd Of Lifeと考えることもできるかもしれない．しかし，それなりの値段の機器が買ってからまだ何年もたっていないのに使えなくなるような事態に陥らないとも限らないのである．

　ネットワークからシステムを修正する方法をもっていれば，こういった現象で困らなくても良くなる．

● タスク間のプロテクション

　最後に，タスク間のプロテクションについて考えておきたい．今後のネットワーク対応装置を考えるとJavaをはじめとするネットワークからのダウンロード可能なアプリケーションという姿が浮かんで来る．

　これは，「永続的な記憶領域」注3が地域的に分散すればするほど保守にかかる費用が増大するからである．もう少し具体的にいうと，1台のサーバコンピュータの中にあるファイルを一つ置き換える手間は1000台の組み込み装置のフラッシュの内容を1バイトだけ変更するより少なくとも1000倍は楽であるということだ．

　「どうせネットワークにつながる装置なのだから，ソフトウェアの大部分はネットワークからもってきてしまえば良いではないか」という発想である．

　この発想を実現するために必要となるのは，まずそのソフトウェアをもってくるシステムの認証，さらにもってきたソフトウェア自身の認証，最後にもってきたソフトウェアが同じシステムの中で並列動作中の他のソフトウェアに与える影響を排除するという技術である．

　このうち認証に関してはすでに述べたとおりである．また，並列動作中の他のソフトウェアへの影響を排除するためにOSに必要とされる要件は，メモリやI/Oなどの資源の保護機能である．もちろん，この機能の実現のためにはいくらかのハードウェア的要件を満たす必要がある．

＊　　　　　　　　　　＊

　さて，このあたりで将来のネットワーク対応組み込み用OSの姿が見えて来たと思う．つまり，

・リソースへのプロテクションがあり
・メタな意味での「ユーザー権限」の概念をもち
・ネットワークに対応したOS

ということになる．

　これは，BSD UNIXがめざしたコンピュータ用のOSに対する要件とほとんど一致する．少なくとも上記の要件の中にあってBSD UNIXに含まれない機能はない．逆にBSD UNIXにあって上記の要件で定義した機能にない機能は「マルチタスク処理」であり，一般のRTOSがサポートし，BSD UNIXがもともとはサポートしていない機能は「リアルタイム性」である．

　これらの機能が必要かどうかは個々のプロジェクトに依存するので，ここであえて追求することは避けることにする．BSDのリアルタイム拡張に関しては，本特集の別章にて解説があるのでそちらを参照してほしい．


■インデックス
　◆インターネット時代の組み込みOSに対するニーズ
　◆ネットワークOSの必要条件
　◆組み込みに使うBSD

今月号特集トップページへ戻る

Copyright 2002 増田佳泰