(57)【要約】【課題】レガシーアプリケーションであっても修正なしでリソースを共有でき、信用できない悪意あるコードを含んでいる可能性のあるアプリケーションであっても、システムのセキュリティやプライバシーに影響を与えずに実行するユーザ空間仮想化を実現する。【解決手段】ネィティブコード命令を逐次的に解釈し、「セキュリティに影響を与え得る処理を行う命令シーケンス」である場合、セキュリティマネージャに実行中のアプリケーションが当該処理を実行する権限を持っているかを問い合わせ、実行中のアプリケーションが当該処理を実行する権限を持っていればフェッチされた命令をそのままＣＰＵで実行し、実行中のアプリケーションが当該処理を実行する権限を持っていなければ、フェッチされた命令を実行しない。ネィティブコード命令が「セキュリティに影響を与え得る処理を行う命令シーケンス」でない場合、ネィティブ命令をそのままＣＰＵで実行する。【選択図】      図１
2008027306.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータで実行することにより、ユーザー空間内で以下のステップを行うことを特徴とするユーザ空間仮想化プログラム
１．アプリケーションのネィティブコードを取り出すステップ、
２．フェッチしたネィティブコードを特定し、下記（１）、（１）−１、（１）−２および（２）の処理を行うステップ
（１）：フェッチしたネィティブコード命令が「セキュリティに影響を与え得る処理を行う命令シーケンス」である場合には、セキュリティマネージャに実行中のアプリケーションが当該処理を実行する権限を持っているかを問い合わせ、
（１）−１：実行中のアプリケーションが当該処理を実行する権限を持っていればフェッチされた命令をそのままＣＰＵで実行し、
（１）−２：実行中のアプリケーションが当該処理を実行する権限を持っていなければ、フェッチされた命令を実行しない。
（２）：フェッチしたネィティブコード命令が「セキュリティに影響を与え得る処理を行う命令シーケンス」でない場合には、フェッチされた命令をそのままＣＰＵで実行する。
【請求項２】
さらに、（１）−２に続いて、
（１）−３：実行中のアプリケーションが当該処理を実行する権限を持っていないことによるエラーを発生させる
ステップを行うことを特徴とする請求項１に記載のユーザ空間仮想化プログラム。
【請求項３】
さらに、（１）−２に続いて、
（１）−３′：フェッチしたネィティブコード命令を、実行中のアプリケーションが実行する権限を持っている処理を行う命令シーケンスに置き換えて、置き換えた命令シーケンスをＣＰＵで実行するステップを行うことを特徴とする請求項１に記載のユーザ空間仮想化プログラム。
【請求項４】
前記（１）−１でアプリケーションが実行する権限を持っていることの確認されたネィティブコード命令については、次回よりセキュリティマネージャへの問い合わせを行うことなく、そのままＣＰＵで実行することを特徴とする請求項１から請求項３のいずれか１項に記載のユーザ空間仮想化プログラム。
【請求項５】
アプリケーションのネィティブコードから「セキュリティに影響を与え得る処理を行う命令シーケンス」を検出し、当該命令シーケンスにかかるネィティブコードから「アプリケーションが権限を持っていることを確認してから、前記『セキュリティに影響を与え得る処理』を行う命令シーケンス」のネィティブコードを生成してＣＰＵで実行することを特徴とする請求項１から請求項４のいずれか１項に記載のユーザ空間仮想化プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ空間の仮想化を行うシステムの技術に関する。
【背景技術】
【０００２】
組み込みシステムに用いられる最新のプラットフォームには、リソースの調停および保護を行うためのリソースマネジメントシステムが求められている。しかしながら、組み込みシステムの機能を最大化するには、リソース調停や保護を行うためにプラットフォームが提供しているAPIを利用しないレガシーアプリケーションや信頼できないアプリケーションの実行も必要となる場合がある。したがって、そのようなアプリケーションについても、プラットフォームが持っているリソースを管理し、セキュリティポリシーを拡大する方法が組み込みの分野でも必要となっている。
【０００３】
組み込み以外の分野における多くの既存オペレーティングシステムには、アクセスコントロール機構が統合されている。著名な例としては、Linux（登録商標）におけるユーザパーミッションチェックが挙げられる。この場合、それぞれのファイルにはオーナーであるユーザIDとパーミッションのモードが関連付けられ、それにより特定ユーザがそのファイルにアクセスできるか否かが決定される。そしてまた、ある種のシステムコールは、スーパーユーザーIDからしか呼び出せないようにすることもできる。さらに、Linuxの”chroot”システムコールによれば、あるプロセスから見えるファイルシステムを制限することができる。
【０００４】
既存のLinuxにおけるユーザIDとパーミッションによるアプローチの問題点は、適切に粒度をコントロールできない点にある。例えば、セキュリティポリシーに関わらず、ファイルの所有者であれば自分のファイルにアクセスしてアクセス制限を任意に変更することが可能である。この問題に対して、SELinuxサブシステムでは、Mandatory Access Controlを実装することで対処している。Mandatory Access Controlでは、自分のファイルであってもアクセス制限を自由に変更することはできず、また、roo権限者のような特権ユーザに対しても権限を制限することができる。しかしながら、SELinuxではLinuxカーネルに手を入れて再コンパイルする必要があり、また、その設定は非常に複雑である。
【０００５】
これに対して組み込みオペレーティングシステムの多くは、アクセスコントロール機構を全く搭載していないというのが現状である。例えば、Symbianのバージョン9.1以前や、WinCEにはユーザIDという概念すら導入されていないし、ユーザーモードプロセスでも大部分のファイルシステム（カーネルからしかアクセスできない一部のシステムファイルを除く）にアクセスすることができる。SymbianOSのバージョン9.1では、このようなOSのセキュリティを強化するための変更がカーネルに対してなされている。
【０００６】
しかし、オペレーティングシステムのカーネルにこのような機能を実装する場合、カーネルに大幅な変更を加える必要があるため、バグ発生のリスクを避けることはできない。また、カーネルに作り込んだアクセスコントロール機構を修正しようとすると修正の度にバグ発生のリスクが生じるので、結果的に修正のコストが高くなり、アクセスコントロール機構の設計から柔軟性が失われるという問題もある。さらに、SELiuxにしても最新のSymbianOSにしても、アクセスコントロールシステムおよびリソースマネジメントシステムは、いずれもOS独自の実装となっており、OSの種類にかかわらず共通的に利用できる機構とはなっていない
また、VMWareやXenといった仮想化技術では、デスクトップやサーバシステムのリソースを分割することが提案されており、このような技術を適用することによってアクセスコントロール機構を実現することも考えられる。しかしながら、このようなアプローチではオペレーティングシステムのほぼ全体を複製しなければならず、メモリ等のリソースについて制限の厳しい組み込みプラットフォームには適用困難である。
【非特許文献１】SELinux, Kerry Thompson, System Admin Magazine, March 2003,  http://www.samag.com/documents/s=7835/sam0303a/0303a.htm
【非特許文献２】Platform Security - a Technical Overview, Version 1.2, Mark Shackman, Symbian Ltd,  http://www.symbian.com/developer/techlib/papers/plat_sec_tech_overview/platform_security_a_technical_overview.pdf
【非特許文献３】QEMU Internals, Fabrice Bellard,  http://fabrice.bellard.free.fr/qemu/qemu-tech.html
【非特許文献４】The Xen Virtual Machine Monitor ,  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
【非特許文献５】VMWare,  http://vmware.com/
【非特許文献６】User-Mode Linu,  http://user-mode-linux.sourceforge.net/
【発明の開示】
【発明が解決しようとする課題】
【０００７】
このような現状を鑑みて、本発明者らは、全く新しいアプローチとしてユーザ空間仮想化（USV; User-space Virtualization）を提案する。
【０００８】
本発明によれば、レガシーアプリケーションであっても、修正を加えることなくリソースを共有することが可能である。本発明はまた、信用できない悪意あるコードを含んでいる可能性のあるアプリケーションであっても、システムのセキュリティやプライバシーに影響を与えることなく実行することができる。さらに本発明は、エミュレーションおよび動的コンパイルの技術を利用することで、アプリケーションによるリソースの利用を厳格にコントロールすることができ、しかもオリジナルのネィティブコード実行速度に近い高いレベルのパフォーマンスを達成するものである。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明の第１の観点は、  
コンピュータで実行することにより、ユーザー空間内で以下のステップを行うことを特徴とするユーザ空間仮想化プログラム  
１．アプリケーションのネィティブコードを取り出すステップ、  
２．フェッチしたネィティブコードを特定し、下記（１）、（１）−１、（１）−２および（２）の処理を行うステップ  
（１）：フェッチしたネィティブコード命令が「セキュリティに影響を与え得る処理を行う命令シーケンス」である場合には、セキュリティマネージャに実行中のアプリケーションが当該処理を実行する権限を持っているかを問い合わせ、  
（１）−１：実行中のアプリケーションが当該処理を実行する権限を持っていればフェッチされた命令をそのままＣＰＵで実行し、  
（１）−２：実行中のアプリケーションが当該処理を実行する権限を持っていなければ、フェッチされた命令を実行しない。  
（２）：フェッチしたネィティブコード命令が「セキュリティに影響を与え得る処理を行う命令シーケンス」でない場合には、フェッチされた命令をそのままＣＰＵで実行する。
【００１０】
を提供する。
【００１１】
本発明においては、さらに、（１）−２に続いて、  
（１）−３：実行中のアプリケーションが当該処理を実行する権限を持っていないことによるエラーを発生させる  
ステップを行う構成とすることができる。
【００１２】
また本発明においては、さらに、（１）−２に続いて、  
（１）−３′：フェッチしたネィティブコード命令を、実行中のアプリケーションが実行する権限を持っている処理を行う命令シーケンスに置き換えて、置き換えた命令シーケンスをＣＰＵで実行する  
ステップを行う構成としてもよい。
【００１３】
さらに、前記（１）−１でアプリケーションが実行する権限を持っていることの確認されたネィティブコード命令については、次回よりセキュリティマネージャへの問い合わせを行うことなく、そのままＣＰＵで実行する構成としてもよい。このような構成とした場合には、同じ命令について何度もセキュリティマネージャに権限を確認することによるオーバーヘッドを軽減することができる。
【００１４】
さらにまた、アプリケーションのネィティブコードから「セキュリティに影響を与え得る処理を行う命令シーケンス」を検出し、当該命令シーケンスにかかるネィティブコードから「アプリケーションが権限を持っていることを確認してから、前記『セキュリティに影響を与え得る処理』を行う命令シーケンス」のネィティブコードを生成してＣＰＵで実行する構成としてもよい。
【発明の効果】
【００１５】
本発明によれば、レガシーアプリケーションであっても修正を加えることなくリソースを共有することが可能であり、信用できない悪意あるコードを含んでいる可能性のあるアプリケーションであっても、システムのセキュリティやプライバシーに影響を与えることなく実行することができる。また、本発明のユーザ空間仮想化プログラムは、オペレーティングシステムのカーネルに修正を加えることなく実装することができるため、ユーザ空間仮想化によってカーネルが複雑化し、システムのメンテナンスが困難とすることはない。しかも、アプリケーションは基本的にネィティブコードの状態で実行されるため、本発明のユーザ空間仮想化によるオーバーヘッドは最小限で済む。また、本発明のユーザ空間仮想化プログラムは、ネィティブコードが同一であればオペレーティングシステムに関わらず使用できるため、同一ＣＰＵを利用したプラットフォームであればオペレーティングシステムの種類を問わずに利用することができる。また、修正が必要となる場合も考えられるが、その修正量は必要最小限で済む。
【発明を実施するための最良の形態】
【００１６】
以下、本発明を実施するための最良の形態について図面を参照しながら説明する。
【００１７】
図１は、本発明を適用した組み込みシステム１００の構成を示す概略図である。図１にはハードウェアとソフトウェアが同時に記載されており、ＣＰＵ１０１上にＯＳ（オペレーティングシステム）１０２が実装され、このＯＳ１０２上でセキュリティマネージャ１０５、ネィティブ命令ハンドラ１０６、ダイナミックコンパイラ１０７が搭載されていて、これらで仮想化されたユーザ空間のＵｎｔｒｕｓｔｅｄ領域１１０内に格納されたアプリケーション１１１が実行されるようになっている。ここで、ＯＳ１０２、セキュリティマネージャ１０５、ネィティブ命令ハンドラ１０６、ダイナミックコンパイラ１０７およびアプリケーション１１１は、いずれもソフトウェアであり、それぞれ所定のプログラムをＣＰＵ１０１で実行することにより実現されるものである。なお、以下ではＡＲＭアーキテクチャ、ＡＲＭ命令を前提とした説明を行う場合もあるが、これらは本発明の理解を助けるための具体例を示しているに過ぎず、本発明で使用するＣＰＵ１０１はＡＲＭに限定されるものではない。なお、上述したそれぞれのソフトウェアは、いずれもＣＰＵ１０１に接続された不図示のメモリ（ＲＯＭ／ＲＡＭ）に格納されており、必要なタイミングでＣＰＵ１０１に呼び出されて実行される。
【００１８】
ＯＳ１０２としては、Ｌｉｎｕｘ、ＷｉｎＣＥ、Ｓｙｍｂｉａｎといった組み込みＯＳを利用することができる。本発明では、ＯＳ１０２が以下の機能を持っていることを想定している。逆に言えば、下記機能またはこれらと等価的な機能を持ったＯＳであれば、前記以外のＯＳであっても本発明の実施に利用することが可能である。
【００１９】
ユーザモード：セキュリティマネージャ１０５、ネィティブ命令ハンドラ１０６、ダイナミックコンパイラ１０７およびアプリケーション１１１をユーザモードで動作させることができ、それぞれのソフトウェアでMMUレジスタを変化させるような特権的な処理を直接実行できないようにする。
【００２０】
メモリ保護：アプリケーション１１１のメモリ空間は、カーネルと同じく他のアプリケーションからも分離される。
【００２１】
Ｉ／Ｏ保護：Ｉ／Ｏ処理はスーパーバイザーモードで実行されなければならず、アプリケーション１１１から直接実行できない（ユーザモードのメモリマップドＩ／Ｏは除く）。
【００２２】
明確なシステムコールインターフェイス：ＯＳ１０２は明確なシステムコールインターフェイスを採用していなければならない。ARMアーキテクチャでは、通常システムコールはSWI命令によって呼び出されるか、特定のマップされていないアドレスへのブランチ命令によって呼び出される。
【００２３】
ページプロテクション修正ＡＰＩ：ＯＳはユーザモードのアプリケーションに対して、アクセスの許されたメモリーページのプロテクションモードを修正するためのＡＰＩを提供しなければならない。
【００２４】
これらＯＳ１０２の機能により、ユーザモードで動作しているアプリケーションにとって、ユーザ空間の外と作用し合う唯一の方法はシステムコールとなる。このシステムコールを検出して管理することにより、アプリケーションによるリソースの利用を正確にモニターおよびコントロールすることができ、システムのセキュリティやプライバシーが危険にさらされることを防ぐことができる。システムコールを検出して管理する方法の一つに、カーネルにシステムコールをフックする機構を設け、フックしたシステムコールのセキュリティチェックを行うことが考えられる。しかし、組み込みシステムでシステムコールをフックすると、アプリケーションのパフォーマンス（実行速度／応答速度）が著しく低下してしまうおそれがある。また、カーネルにフック機構を導入するために手を加えると、バグ発生のリスクがあることも前述した通りである。
【００２５】
そこで、本発明では、システムコールをフックするのではなく、以下のようなユーザ空間の仮想化（ＵＳＶ；Ｕｓｅｒ  Ｓｐａｃｅ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）によって、システムのセキュリティを実現する。ＵＳＶの中心になっているアイデアは、「ネィティブエミュレーション」である。ＵＳＶを適用した場合も、ネィティブ命令にコンパイルされたアプリケーションのプログラムを実行するという点では既存のシステムと同様である。しかし、この場合にアプリケーション１１１のネィティブ命令は、ＣＰＵ１０１によって直接実行されるのではなくＵＳＶによって仮想化されたシステム上で実行されるものであり、この点で本発明は既存のシステムと大きく相違する。また、ＵＳＶは組み込みシステムの仮想化に加えて、さらに以下の２つの重要な機能を持っている。
【００２６】
・安全性を検証し、リソース共有を実現するためにシステムコールを捕捉する。
【００２７】
・ホットスポットを動的にコンパイルし、ＣＰＵで直接実行できるようにする。
【００２８】
以下、本発明のＵＳＶを実現する各ソフトウェアについて説明する。これらのソフトウェアは、いずれもユーザ空間内で実行されるものである。
【００２９】
ネィティブ命令ハンドラ１０６は、ユーザ空間内でアプリケーション１１１を実行する際に利用されるものであり、実行されるアプリケーション１１１に含まれるネィティブ命令を取り出し（読み出し）、「セキュリティに影響を与え得る処理を行う命令シーケンス」を検出した場合、当該命令シーケンスをダイナミックコンパイラ１０７にコンパイルさせ、コンパイル後のコードをＣＰＵ１０１に実行させる機能を有している。その一方で、「セキュリティに影響を与え得る処理を行う命令シーケンス」以外のネィティブコードについては、ＣＰＵ１０１にそのまま実行させる。ここで、「セキュリティに影響を与え得る処理を行う命令シーケンス」とは、システムコールを呼び出すためのＳＷＩ命令や図４に示すようなコードを含みシステムコールを呼び出す命令シーケンスのことである。
【００３０】
ダイナミックコンパイラ１０７は、ネィティブ命令ハンドラ１０６が検出した前記「命令シーケンス」を「Ｓａｆｅネィティブ命令」にコンパイルする。ここではコンパイルと称しているが、実際の処理は「ＣＰＵ１０１のネィティブ命令のシーケンスから、同じネィティブ命令からなるセキュリティチェックの処理が付加された別のシーケンスを生成する」ことにある。図６および図７はダイナミックコンパイラ１０７によるコンパイルの内容を説明するためのものであって、図６はコンパイル前のコードを、図７はコンパイル後のＳａｆｅネィティブ命令をそれぞれニーモニックで示している。なお、図７中のｉｎｔｅｒｃｅｐｔ＿ｏｐｅｎ（）とは、システムコールｏｐｅｎ（）を捕捉して、セキュリティチェックを実行するルーチンを呼び出し、セキュリティチェックをパスした場合のみ実際にシステムコールｏｐｅｎ（）を呼び出す仮想的なニーモニックである。この例に示されるように、Ｓａｆｅネィティブ命令とは、コンパイル前のコードに、セキュリティチェックを行ってからコンパイル前のコードに相当する処理を実行するコードに書き換えたものである。
【００３１】
両者のコードを比較すると分かるように、ダイナミックコンパイラ１０７はシステムコールを呼び出す命令シーケンスを、システムコール呼び出し前にセキュリティチェックをかける命令シーケンスにコンパイルする。したがって、セキュリティに影響を与えうる命令シーケンスはそのまま実行されず、必ずセキュリティチェックを受けることになる。なお、このようなコンパイルによって生成された「Ｓａｆｅネィティブ命令」は、アプリケーション１１１の元のコードが格納されているのとは別の所定メモリ領域に保存される。
【００３２】
上記ダイナミックコンパイラ１０７は、高級言語のソースコードからネィティブコードを生成する通常のコンパイラと比較して、その処理は単純であり、複雑な最適化処理を施すものでもない。このため、ダイナミックコンパイラ１０７のサイズは通常のコンパイラよりもコンパクトとなり、コンパイルする処理がシステムにおよぼすオーバーヘッドも軽微なものとなる。したがって、リソース制限の厳しい組み込みシステムにおいても十分利用することが可能である。
【００３３】
このようなネィティブ命令ハンドラ１０６とダイナミックコンパイラ１０７により、アプリケーション１１１の実行中にネィティブ命令ハンドラ１０６が前記「命令シーケンス」を検出すると、アプリケーション１１１の実行は一旦中断され、ダイナミックコンパイラ１０７が前記「命令シーケンス」のコンパイルを行って「Ｓａｆｅネィティブ命令」を生成し、前記所定のアドレスに配置する。次に生成された「Ｓａｆｅネィティブ命令」をＣＰＵ１０１で実行することによりアプリケーション１１１の実行が再開され、生成された「Ｓａｆｅネィティブ命令」の実行が終わると、前記「命令シーケンス」の続きからネィティブ命令ハンドラ１０６による前記「命令シーケンス」の検出を受けつつアプリケーション１１１のネィティブ命令がＣＰＵ１０１で実行される。
【００３４】
セキュリティマネージャ１０５は、Ｕｎｔｒｕｓｔｅｄ領域１１０に格納されたアプリケーション１１１について、許可および／または許可しない命令シーケンスの情報を記述したセキュリティコンフィグレーションファイルを保持しており、これによりアプリケーション１１１が「セキュリティに影響を与え得る処理を行う命令シーケンス」を実行しようとした場合に、その可否を判断する機能を有している。セキュリティコンフィグレーションファイルの形式には特に制限はなく、例えばＸＭＬ形式を利用することができる。また、セキュリティコンフィグレーションファイルには、アプリケーションごとにアクセスできるアドレス範囲やファイル種別、ハードウェアリソースを記述し、アドレス範囲やファイル種別、ハードウェアリソースに応じてアクセスの可否を判断させるようにしても構わない。
【００３５】
以下、本発明のユーザ空間仮想化技術によって、ユーザモードで実行されるネィティブ命令ハンドラ１０６およびダイナミックコンパイラ１０７が、セキュリティマネージャ１０５と連携してアプリケーション１１１を実行する際の動作について説明する。図２は図１で示した各ソフトウェアモジュールの連携を示す図面であり、図３は各モジュールによる動作をフローチャートにまとめたものである。
【００３６】
まず、ネィティブ命令ハンドラ１０６が、ユーザ空間内にロードされたアプリケーション１１１のプログラムコードから実行すべきネィティブ命令を取り出す（ＳＴ１０１）。取り出すネィティブ命令は一つずつでも良いし、複数のネィティブ命令を取り出すようにしても構わない。
【００３７】
次に、ネィティブ命令ハンドラ１０６は、取り出されたネィティブ命令がセキュリティに影響を与え得る処理を行うか否かについて判断を行う（ＳＴ１０２）。この判断は、事前にセキュリティに影響を与え得る処理を行うものとして登録されたネィティブ命令やそのシーケンスが、取り出されたネィティブ命令に含まれているかに基づいて行われる。
【００３８】
ＳＴ１０２において、取り出されたネィティブ命令がセキュリティに影響を与え得る処理を行うものではないと判断された場合、ネィティブ命令ハンドラ１０６が取り出したネィティブ命令は、そのままＣＰＵ１０１で実行される（ＳＴ１０３）。
【００３９】
一方、ＳＴ１０２において、取り出されたネィティブ命令がセキュリティに影響を与え得る処理を行うものであると判断された場合、ダイナミックコンパイラ１０７により取り出されたネィティブ命令のコンパイルが行われ、セキュリティチェックを行ってからコンパイル前のコードに相当する処理を実行するＳａｆｅネィティブ命令１０９が生成され、所定のアドレスに配置される（ＳＴ１０４）。
【００４０】
以降、ＳＴ１０４において生成されたＳａｆｅネィティブ命令１０９がＣＰＵ１０１により実行される。これにより、まず、セキュリティマネージャ１０５に対し、アプリケーション１１１がセキュリティに影響を与え得る処理を実行する権限を持っているかの問い合わせがなされる（ＳＴ１０５）。この問い合わせを受けたセキュリティマネージャ１０５は、アプリケーション１１１について許可および／または許可しない処理の情報を記述したセキュリティコンフィグレーションファイル１０８を参照し、その記述に基づいて権限の有無を判断する（ＳＴ１０６）。
【００４１】
ＳＴ１０６において、セキュリティマネージャ１０５がアプリケーション１１１が権限を持っていると判断した場合、ＳＴ１０１においてアプリケーション１１１から取り出されたネィティブ命令に相当するコードがＣＰＵ１０１で実行される（ＳＴ１０７）。図２中では、ＯＳカーネル１０３にシステムコールが発行され、カーネル空間内でＯＳカーネル１０３からリソース１０４へアクセスする場合を例示している。一方、アプリケーション１１１が権限を持っていないと判断した場合には、取り出されたネィティブ命令に相当する処理は行わない（ＳＴ１０８）。図２中では、システムコール発行を拒否する場合を例示している。
【００４２】
以上のようにして、アプリケーション１１１から取り出したネィティブ命令を実行した後、次に実行すべきネィティブ命令について、ＳＴ１０１からの処理が繰り返されアプリケーション１１１は実行される。なお、ＳＴ１０８において取り出したネィティブ命令を実行しなかった場合には、権限違反のエラーが発生したことをアプリケーション１１１に通知するとともにアプリケーション１１１の実行を中止しても良いし、可能であればアプリケーション１１１が権限を持っている代替的な処理を行ってアプリケーション１１１の実行を継続するようにしても構わない。
【００４３】
以上のような処理によれば、ネィティブ命令からなるアプリケーション１１１のプログラムについて、セキュリティのチェックを逐次的に行うことができ、これによりレガシーアプリケーションであっても修正を加えることなくリソースを共有することが可能となり、信用できない悪意あるコードを含んでいる可能性のあるアプリケーションであっても、システムのセキュリティやプライバシーに影響を与えることなく実行することができる。また、セキュリティチェックは逐次的に行われるので、アプリケーション１１１の実行前に一括して行う場合よりも、セキュリティチェックのオーバーヘッドを分散させることができる。さらに、実際に実行されるコードだけがセキュリティチェックの対象となるので、セキュリティチェックによるシステム負荷を最小限とすることができる。
【００４４】
さらにまた、本発明は、オペレーティングシステムのカーネルに修正を加えることなく実装することができるため、カーネルを複雑化することはなく、カーネルレベルで深刻なバグを引き起こすこともない。しかも、アプリケーション１１１はネィティブコードの状態で実行されるため、ネィティブ命令ハンドラ１０６やダイナミックコンパイラ１０７の影響にかかわらず、アプリケーション実行のパフォーマンスは十分に高い。また、本発明の基本的なアーキテクチャは、オペレーティングシステムやＣＰＵに依存しないので、本発明は様々なプラットフォームに適用することができる。
【００４５】
以上、本発明の一実施形態について説明したが、本発明の実施形態は上記に限られるものでなく、種々変形および応用が可能なことは言うまでもない。例えば、上記では、ダイナミックコンパイラ１０７によりＳａｆｅネィティブ命令１０９を生成する場合を示したが、ネィティブ命令ハンドラ１０６でネィティブ命令をインタープリタ的に解釈実行するようにしても良く、この場合にはダイナミックコンパイラは省略可能である。また、ダイナミックコンパイラ１０７により生成されたＳａｆｅネィティブ命令１０９については、キャッシュして再利用できるようにしても良い。さらに一度セキュリティチェックをパスしている場合には、Ｓａｆｅネィティブ命令１０９にセキュリティチェックを行う命令を削除／簡略化する等の修正を加えて保存しても良いし、アプリケーション１１１のネィティブ命令をＣＰＵ１０１でそのまま実行するようにしても構わない。
【００４６】
また、セキュリティマネージャ１０５には、アプリケーションの権限を確認する機能に加えて、アプリケーションによるリソース使用を制御する機能を設けても良く、このようにすれば組み込みシステムにおけるリソース共用で問題となるリソースの調停、すなわち複数アプリケーションが同じリソースを同時に使おうとした場合に、各アプリケーションの性質やシステムの設定に応じてリソースの使用権を割り振ることが可能となる。このようにすることで、アプリケーション側では意識することなく、複数のアプリケーションをマルチタスクで動作させる複雑な組み込みシステムを効率よく開発することが可能となる。
【図面の簡単な説明】
【００４７】
【図１】組み込みシステム１００の構成を示す概略図。
【図２】各ソフトウェアモジュールの連携を示す図面。
【図３】各モジュールによる動作をまとめたフローチャート。
【図４】システムコールを呼び出す命令シーケンスの例。
【図５】ｏｐｅｎ（）システムコールを取り扱う例。
【図６】コンパイル前のコード例。
【図７】図４のコードをコンパイルして得られたＳａｆｅネィティブ命令の例。
【符号の説明】
【００４８】
１００…組み込みシステム、１０１…ＣＰＵ、１０２…ＯＳ、１０５…セキュリティマネージャ、１０６…ネィティブ命令ハンドラ、１０７…ダイナミックコンパイラ、１０８…セキュリティコンフィグレーションファイル、１０９…Ｓａｆｅネィティブ命令、１１０…Ｕｎｔｒｕｓｔｅｄ領域、１１１…アプリケーション。
【図１】
2008027306.tif 000003
【図２】
2008027306.tif 000004
【図３】
2008027306.tif 000005
【図４】
2008027306.tif 000006
【図５】
2008027306.tif 000007
【図６】
2008027306.tif 000008
【図７】
2008027306.tif 000009