(57)【要約】【解決手段】組み込みパッチの管理のための方法、システム、および装置が提供される。１つの実施形態では、方法が提供される。この方法は、コードモジュールに対する呼び出しを受信することを含む。方法は、更に、許可の表示があるかどうか、防護スタックをチェックすることを含む。防護スタックは、実行スタックとは別である。方法は、また、呼び出しを内部コードモジュールに引き渡すことを含む。更に、方法は、コードモジュールを実行することを含む。【選択図】図１１
2009509273.tif 000002
【特許請求の範囲】
【請求項１】
コードモジュールに対する呼び出しを受信する工程と、
実行スタックとは別の防護スタックを、許可の表示についてチェックする工程と、
前記呼び出しを内部コードモジュールに引き渡す工程と、
前記コードモジュールを実行する工程と、
を備える方法。
【請求項２】
請求項１に記載の方法であって、更に、
前記許可の表示に基づく前記コードモジュールに対する前記呼び出しを検証する工程を備える方法。
【請求項３】
請求項１に記載の方法であって、更に、
誤った許可の表示に基づくコードモジュールに対する呼び出しをブロックする工程を備える方法。
【請求項４】
請求項１に記載の方法であって、更に、
前記コードモジュールの実行の結果を戻す工程を備える方法。
【請求項５】
請求項４に記載の方法であって、更に、
前記内部コードモジュールから内部結果を戻す工程と、
前記内部結果を前記結果として提供する工程と、
を備える方法。
【請求項６】
請求項１に記載の方法であって、更に、
前記コードモジュールに対する引数をチェックする工程を備える方法。
【請求項７】
請求項１に記載の方法であって、更に、
前記内部コードモジュールのマーク命令に応答して、マークキューにマークを記す工程を備える方法。
【請求項８】
請求項７に記載の方法であって、更に、
予期されるマーク命令に基づいて、前記マークキューをマークについてチェックする工程を備える方法。
【請求項９】
請求項８に記載の方法であって、更に、
前記マークキューへの誤ったエントリに応答して、エラーをシグナル通知する工程を備える方法。
【請求項１０】
請求項８に記載の方法であって、更に、
タイマに応答して、前記マークキューをチェックする工程を備える方法。
【請求項１１】
請求項８に記載の方法であって、
前記予期されるマーク命令は、グラフとして格納される、方法。
【請求項１２】
命令を組み入れたマシン読み取り可能な媒体であって、
前記命令は、実行時にプロセッサに方法を実施させ、
前記方法は、
コードモジュールに対する呼び出しを受信する工程と、
実行スタックとは別の防護スタックを、許可の表示についてチェックする工程と、
前記呼び出しを内部コードモジュールに引き渡す工程と、
前記コードモジュールを実行する工程と、
を含む、マシン読み取り可能な媒体。
【請求項１３】
請求項１２に記載のマシン読み取り可能な媒体であって、
前記マシン読み取り可能な媒体は、ソフトウェアシステムに対するパッチを組み入れており、前記パッチは、前記方法を実行する命令を含む、マシン読み取り可能な媒体。
【請求項１４】
請求項１３に記載のマシン読み取り可能な媒体であって、
前記パッチは、受信デバイスのソフトウェアシステムに取り込むために、前記受信デバイスに配布することができる、マシン読み取り可能な媒体。
【請求項１５】
請求項１２に記載のマシン読み取り可能な媒体であって、
前記方法は、更に、
前記コードモジュールに対する引数をチェックする工程と、
前記許可の表示に基づく前記コードモジュールに対する前記呼び出しを検証する工程と、
前記内部コードモジュールから内部結果を戻す工程と、
前記コードモジュールの実行の結果として前記内部結果を提供する工程と、
前記コードモジュールの前記実行の結果を戻す工程と、
を含む、マシン読み取り可能な媒体。
【請求項１６】
請求項１２に記載のマシン読み取り可能な媒体であって、
前記方法は、更に、
前記内部コードモジュールのマーク命令に応答して、マークキューにマークを記す工程と、
予期されるマーク命令に基づいて、前記マークキューをマークについてチェックする工程と、
を含む、マシン読み取り可能な媒体。
【請求項１７】
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合されたユーザインターフェースと、
前記プロセッサに結合されたネットワークインターフェースと、
を備えるシステムであって、
前記プロセッサは、
コードモジュールに対する呼び出しを受信し、
実行スタックとは別の防護スタックを、許可の表示についてチェックすることと、
前記呼び出しを内部コードモジュールに引き渡すことと、
前記内部コードモジュールを実行することと、
を行うものである、システム。
【請求項１８】
請求項１７に記載のシステムであって、
前記プロセッサは、更に、
前記コードモジュールに対する引数をチェックすることと、
前記許可の表示に基づく前記コードモジュールに対する前記呼び出しを検証することと、
前記内部コードモジュールから内部結果を戻すことと、
前記コードモジュールの実行の結果として前記内部結果を提供することと、
前記コードモジュールの前記実行の結果を戻すことと、
を行うものである、システム。
【請求項１９】
請求項１７に記載のシステムであって、
前記プロセッサは、更に、
前記内部コードモジュールのマーク命令に応答して、マークキューにマークを記すことと、
予期されるマーク命令に基づいて、前記マークキューをマークについてチェックすることと、
を行うものである、システム。
【請求項２０】
請求項１７に記載のシステムであって、更に、
データを不揮発式に格納するための手段を備えるシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
ネットワークは、多数のデバイスで動作することができる。このようなデバイスは、全て同一タイプであるかもしれないし、あるいは多くの異なるタイプで、異なる処理を必要とするかもしれない。このようなデバイスに対するアップデートの管理は、難しい課題である。プロセスは、たまにのみつながれるデバイスに対する対デバイスアップデートの追跡と、様々なタイプの加入者のヴァージョンの追跡との間で非常に複雑になる。
【０００２】
ネットワークは、リアルタイムで動作する。したがって、ハードウェアに対するパッチを送信する場合は、アップデートを可能にするためにダウンサイクルを待つのではなく、そのパッチを動的に追加する必要がある。また、動的リンクメカニズムおよび検査メカニズムを提供すると有用であると考えられる。
【発明の開示】
【０００３】
本発明は、各種の代表的実施形態のかたちで例示され、添付の特許請求の範囲によってのみその趣旨および範囲を限定される。
【０００４】
各種の図面において、類似の参照符号は、類似の要素を示すものとする。
【０００５】
本発明は、各種のシステム、装置、および方法に関連して説明され例示される。この発明の概要において説明される本発明の態様に加えて、本発明の更なる態様が、図面の参照および以下の詳細な説明によって明らかになる。
【０００６】
ソフトウェアパッチおよびその他のコードセグメントは、様々な方式で実装することができる。方法、手順、および関数に防護層を提供することによって、コードは、よりセキュアにすることが可能である。１つの実施形態では、オブジェクト、すなわちコード部分を包むラップとして、防護層が提供される。これは、外界とのインターフェースを表しており、無許可のソースからのアクセスを排除するために使用することができる。これは、信頼のおけるソースからでもそうでなくもありうる対コードパッチにとって、とりわけ有用である。したがって、パッチの配布にあたっては、パッチのコードのための付随の防護層が、プロセスにおいてセキュリティをもたらすのに役立つことができる。
【０００７】
パッチ管理システムは、いくつかの標準ベースのコンポーネント、すなわち通知システムと、パッチ配信プロトコルと、パッチ抽出と、最終的な適用パッチとを含むことができる。
【０００８】
中央のポイントからその他の多くのネットワークポイントへと通知を送信するには、多くの選択肢がある。多様なカスタマーベースにとっては、ホームネットワーク、公共のカフェ、および企業ではもちろん、保護されていない野ざらしのインターネットでも動作する、強固なプロトコルが有用であると考えられる。このような基準に基づくと、解決策は、ファイアウォールおよびNATの干渉を回避するために好ましくはTCP/IPベースであり、終端デバイスは、好ましくは中央の配布サーバにつながれる。
【０００９】
パッチの通知において上手く動作するであろう２つの標準ベースのプロトコル（もっと多く存在しうる）は、SIP（セッション開始プロトコル：VoIP通話を通知および維持するために使用されるプロトコル）およびJabber/XMMP（インスタントメッセージングプロトコル）である。SIPは、通常、UDP上で走るが、TCP/IP上で走るようにすることもできる。いずれのプロトコルも、SSL上でトンネル可能である。
【００１０】
ビットトレント（BT）は、インターネット上において現在最も普及しているプロトコルであり、e-mailおよびHTTPトラフィックを軽くする。ビットトレントは、大きなファイル画像（例えばDVD）を配信するのに、そしてその画像を非常に多くのピア（XX,000s同時ダウンロード）に配信するのに最適である。ビットトレントは、一般に、HTTP上で走り、これは、ウェブブラウザに一体化させること、およびウェブブラウザとともに使用することを容易にする。しかしながら、組み込みデバイスアプリケーションの場合は、BTをHTTP上で走らせることの技術的な必要性がない。BTプロトコルメッセージングは、HTTPに非常に似ているが、容易にパケット化可能であることによって処理を容易にしかつ性能を高速化する。
【００１１】
BTプロトコルのバイナリヴァージョン（組み込みビットトレント）は、今日のブラウザにおいて使用される一般的なBTより小さくかつ高速で、HTTPを必要としないゆえに、好ましいとされる。これは、あらゆる余分なメッセージ処理を回避することができる。なぜならば、このようなメッセージ処理は、コードおよびCPU処理の追加を多く必要とするとともに、アタックおよびエクスプロイトを招く傾向があるからである。
【００１２】
もしカスタマのデバイスが、入来するビットトレントのクライアント接続をブロックするNATまたはファイアウォールの背後でのみ動作する場合は、（パッチの）告知を減速させると有用であると考えられる。BTおよびSIPの代わりにJabberを使用することも考えられる。
【００１３】
いくつかの実施形態において、パッチおよびファームウェア画像は、転送時における改ざんを阻止するために、暗号処理によって保護される。パッチは、デジタル的にセキュアなエンベロープに封入される（PKCS#7/12）。オプションとして、パッチは、部外者によるパッチの検査を阻止するために暗号化される。これは、全て、PKCS#7/12から基本的に自由に与えられる。PKCSメッセージのペイロードは、パッチ／ファームウェア画像を記述するメタデータを含む。メタデータは、ヴァージョン番号情報、およびその他のオブジェクトのクロス依存性を含む。メタデータは、最終的には、動的データオブジェクトをどのように「アップデート」するかに関する情報も含むことができる。
【００１４】
パッチが配信され、カプセル化を解除された後は、ファームウェア画像全体で交換される、あるいは画像からの先のオブジェクトファイルに代えて新しいオブジェクトファイルを動的にリンクする必要がある。ダウンタイムなしにモジュールを交換可能であることが、最終ヴァージョンの課題である（「ホットリストアップデート」）。動的リンクは、そのレベルに極めて近づくものの、C言語は柔軟であるので、動的アップデートに反する働きをする。したがって、自己記述的でかつ将来のパッケージに対してマッピング可能であるようなデータレポジトリが望ましいとされる。
【００１５】
ホットリストアップデートサポートは、スレッド、ミューテックス、データディクショナリなどのクリティカル動作を層でラッピングすることを必要とする。割り込み性ではあるものの、オペレーティングシステムおよびアプリケーションに対する変更は、いずれも、最小限に抑えられることが望ましく、アプリケーションおよびオペレーティングシステムによって感知できないことが理想的である。組み込みリンカを活用すれば、以下の命名規則：wrap<Operation>（例えばwrap_spawnThread）をともなうオブジェクトコード層を有することによって、クリティカル動作をラッピングすることが可能である。注：シンボルレベルでは、Cメソッドは下線からスタートする。
【００１６】
シンボル名の先頭に「wrap」を追加することによって、リンカは、先ず、ラッピングの呼び出しを本来の動作に結合し、そのシンボルを取り除き、次いで、ラップシンボル名を本来の動作名に改名する。明らかに、これは、その他の方式で実装して同じ効果を実現することが可能である。
【００１７】
wrap_spawnThreadが、spawnThreadを呼び出す
リンカが、spawnThreadを解析する
リンカが、wrap_spawnThreadをspawnThreadに改名する
【００１８】
すると、アプリケーションコードは、いかなる変更もなく、無意識にwrap_spawnThreadを呼び出すことができる。wrap_spawnThreadは、すると、ダウンタイムパッチを行わない目的で、そしてアプリケーションが限定動作を実施しているかどうかを決定するためにアプリケーションを監視する目的で、アプリケーションを追跡することができる。この同じ技術は、コードの追跡を行う目的で、汎用のオブジェクト／ライブラリインターフェース（API）に適用することができる。この技術の使用によって、スレッドプロファイルを作成することができ、もし、そのスレッドプロファイルがねじれている（例えば電子決済ストレージに不正にアクセスするスレッドであるなどの）場合は、そのアクセスをブロックすることが可能である。これは、防護層、すなわちオブジェクトまたはコード部分を包むラップであり、外界とのインターフェースを提供し、無許可のソースからのアクセスを排除するために使用することができる。
【００１９】
また、デバイスのオブジェクトコードの自己監査／保全性検査（例えばオブジェクトコード署名の検査）を別の防護とすることも可能である。ただし、これらは、システムの起動時にのみ利用可能である場合がほとんどである。デバイス故障の発生時に新しいコードを切り離して古いコードにリンクすることによってパッチを取り消す能力も、また、含まれることが可能である。
【００２０】
二次スタックのためのラッパー層が追加されると、ハッカーは、どのようにすればそのコードをリアルタイムで飛び越えられるかを突き止めるために、ラッパーコードをのぞき見ようと試みる、あるいは単純に、ハードワイヤードアドレスを使用しようと試みる。この種の、壁を飛び越える攻撃を阻止するため、各ラッパー関数は、ラッパーコードの先頭に、ジャンクコードを有することができる。このジャンクコードは、任意の自動ワームがAPIの真でかつ正しい本来のアドレスを嗅ぎつける試みを混乱させるため、長さが（命令の点から見て）ランダムでありなおかつ結果がランダムである。単純なハードワイヤードジャンプを阻止するため、モジュールの順序もまた、ランダムであることが可能である。
【００２１】
コードタンブラもまた、実装することが可能である。これらは、基本的に、その他のモジュールへとクロスするが任意の順序で完了することができるコード動作である。基本的に、一群のモジュールに対する呼び出しは、ランダムに順序付けることが可能である。これは、より多くのタンブラを追加するために、何度かつなぎあわせることができるので、より大きなロックの場合は、複数のタンブラの組み合わせとなり、真のコードのみが、その厳密な組み合わせによってプログラムされている。したがって、たとえ何者かが他の防御層を突破した場合でも、コードタンブラは、性能に対する影響を比較的最小に抑えつつ、打ち負かすための別の層を提供する。
【００２２】
ワームは永続的であるので、たとえ様々な層によって次々に攻撃をかわしても、いくらかの時間が経過すると、ワームが防護層をすり抜ける可能性がある。この統計的攻撃に対抗するため、どのモジュールがデバイスに到る本来のセキュリティホールであったかを決定することができる。オペレーションシステムは、攻撃に成功したのがデバイス上のどのソケットであるか、したがってどの起点IPアドレス／ポートであるか、そしてどのポート／サービスであるかを知ることができる。システムは、すると、所定の方針に基づいて、そのIPアドレスからの全てのトラフィックまたはそのポートへの全てのトラフィックをブロックすることができる。このような方針は、極めてパラノイドであってもよいし、あるいは、例えば一定の数のアドレスから所定の閾値回数の試みがあった後にトリガするように設定されてもよい。ワームは、多数のポイントから同時に攻撃することができるので、このような閾値は、とりわけ有効であると考えられる。
【００２３】
パッチ管理サーバは、いくつかの標準ベースのコンポーネント、すなわちパッチビルダ、パッチ検査システム、パッチコンソール、通知システム、およびパッチ配信プロトコルを含む。
【００２４】
好ましくは、必要とされるインターフェースのみが公開され、動的にリンク可能である。どのAPIが必要でないかを決定するためには、問題の領域を探して不要なAPIを排除するためにコードを解析するようなツールを使用することができる。このタスクを手動で行うと、非常に多くの人手が必要とされ、人為的ミスを生じやすい。典型的なデバイス画像内には、実際、何千もの未使用のAPIが存在しうる。ツールは、また、コードの最適なブロック構成を決定することができ、これは、必要に応じて手動で調整可能である。
【００２５】
パッチの構築後は、変化が許可されフィールド内へと送信されるのに先立って、厳密なパッチ検査システムを適用することができる。デバイスパッチに対して自動化テストを実施するため、汎用のテストネットワークフレームワークを拡張することが可能である。あらゆるデバイス行為の組み合わせをテストして劣ったパッチを回避するため、テストネットワークフレームワーク内においてデバイスの内部状態マシンを複製することが可能である。
【００２６】
パッチ管理サーバは、コンソールを使用することによって、配布されるパッチの進行状態をチェックし、パッチを受信するカスタマ（内部開発のベータカスタマ、汎用リリースのプラチナカスタマなど）を割り当て、異常（例えばパッチ障害）を探し、パッチをリリースするための方針および規則をセットアップする。パッチが読み込まれ、リリースの用意が整うと、SIP（またはJabberでもよい）告知が加入デバイスへと送信される。告知メッセージは、リリースヴァージョン、その他の所要コンポーネント、およびダウンロード命令（ビットトレント、HTTPなど）などの、パッチに関するメタ情報を含む。メッセージは、盗用および改ざんを阻止するために、SSLを通して送信することができる。告知のリリースは、例えばダウンロードプロトコル（ビットトレント vs、HTTP vsなど）、複合デバイス構成の混合（未知の辺の場合を網羅するため）、地理的位置、およびその他の要因に基づいて、減速することができる。サーバの視点から見たパッチ配信は、改変されたビットトレントプロトコル、標準的なHTTP、またはその他のプロトコルなどの、単純なダウンロードメカニズムである。
【００２７】
パッチ管理システムは、先ずは、エラーがないかどうか、画像を受信する全てのデバイスをチェックする。ダウンロード人口が増えるにつれ、ランダムなデバイス人口サブセットを障害について監視することができる。最終的には、検討のために、包括的なダウンロード状態を提供することができる。
【発明を実施するための最良の形態】
【００２８】
様々な実施形態では、各種のコードモジュールまたはコードセグメントを使用することが可能である。図１は、コードモジュールの一実施形態を示している。コードモジュール１００は、例えば関数または手順を実装可能なソフトウェアを含む。あるいは、コードモジュール１００は、例えば１つまたは複数のメソッドを実装するオブジェクトであることが可能である。図２は、コードAPIの一実施形態を示している。コードAPIは、例えば引数をともなわない関数：foo()およびbar()を含むことが可能である。したがって、図２のコードAPIは、コードモジュール１００に対応しており、コードモジュール１００の機能にどのようにアクセスするかに関する情報を提供することが可能である。
【００２９】
防護層が含まれる場合は、コードセグメントは、異なるアプローチをとる。図３は、コードモジュールの代替の一実施形態を示している。コードモジュール３００は、より従来のコードモジュールとともに、防護層を含む。コードモジュール１００は、図１に示されたような、従来のコードモジュールである。防護層３１０は、コードモジュール１００のためのラッパーとして機能する追加のコードコンポーネントまたはコードモジュールである。図４は、コードモジュール３００とともに使用可能であるような、コードAPIの代替の一実施形態を示している。コードモジュール３００のためのAPIは、関数：foo()およびbar()を含む。この場合のコードモジュール１００は、ソフトウェアルーチンとしてfoo_internal()およびbar_internal()を提供する。しかしながら、foo()およびbar()は、外界とのインターフェースである。コードモジュール１００内の対応するルーチンを呼び出すのに加えて、防護層３１０のソフトウェアルーチンは、ソフトウェア全体の動作を検証する。これは、内部ルーチンに対する呼び出しを引き渡す前に、ルーチンに対するあらゆる呼び出しを先ず検証することによって達成することができる。
【００３０】
ソフトウェアの動作の一例を検討すると有益であると考えられる。図５は、コードセグメントのシステムの一実施形態を示している。コードセグメントのセットとプログラムスタックとが、セグメント間の呼び出しとともに示されている。システム５００は、プログラムスタック５４０とともに、コードセグメント５１０，５２０，５３０を含む。図に示されるように、セグメント５１０内のルーチンに対して呼び出しがなされる。セグメント５１０は、セグメント５２０内のルーチンに対して呼び出しを実行する。同様に、セグメント５２０は、セグメント５３０内のルーチンに対して呼び出しを実行する。これらの各呼び出しは、従来のシステムに状態情報を格納するために、プログラムスタック５４０を使用することをともなう。
【００３１】
図６は、コードセグメントのシステムの代替の一実施形態を示している。各コードセグメント５１０，５２０，５３０は、それぞれに関連付けられた防護層（６１０，６２０，６３０）を有する。すると、コード遷移は、コードセグメントを直接通してではなく、中間メカニズムの防護層を通して生じる。これは、アプリケーションに対するモジュラ式のアプローチをなおも維持しつつ、コード遷移を検証または認証することを可能にする。コード遷移は、例えば、手順の呼び出し、関数の呼び出し、またはオブジェクトメソッドのアクティブ化を含むことができる。
【００３２】
検証方法の１つは、別個の防護スタック６４０の使用をともなう。このシステムを使用するコードセグメントは、防護スタック６４０上の状態情報をプッシュする。この状態情報は、すると、コードセグメント（防護層）によって、コード遷移を受信して手順または関数の呼び出しが信頼のおけるソースからであるかどうかを決定するために使用される。状態情報は、呼び出しの発信元に関する表示のように、単純であってもよいし、あるいは、例えば暗号化状態情報または個別識別情報などの情報を含む、より複雑なものであってもよい。
【００３３】
図７〜８についての以下の説明は、上述されたおよび後述される本発明の方法を実施するのに適したコンピュータハードウェアおよびその他のオペレーティングコンポーネントの概要を示すことを意図しているが、適用可能な環境を限定することは意図していない。同様に、コンピュータハードウェアおよびその他のオペレーティングコンポーネントは、上述された本発明の装置の一部として適していることが可能である。本発明は、携帯用デバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラマブルな家庭用電子機器、ネットワークパソコン、ミニコン、メインフレームコンピュータなどの、その他のコンピュータシステム構成において実行することができる。本発明は、また、通信ネットワークを通じて結合される遠隔処理デバイスによってタスクを実施される分散コンピューティング環境においても実行することができる。
【００３４】
図７は、インターネットなどのネットワーク７０５を通じてつなぎあわされたいくつかのコンピュータシステムを示している。本明細書において使用される「インターネット」という用語は、TCT/IPプロトコルなどの特定のプロトコル、および場合によってはワールドワイドウェブ（WEB）を作成するハイパーテキストマークアップ言語（HTML）のためのハイパーテキスト転送プロトコル（HTTP）などのその他のプロトコルを使用する、ネットワークのネットワークを意味する。インターネットの物理的接続、ならびにインターネットのプロトコルおよび通信手順は、当業者に周知である。
【００３５】
インターネット７０５へのアクセスは、一般に、ISP７１０，７１５などのインターネットサービスプロバイダ（ISP）によって提供される。クライアントコンピュータシステム７３０，７４０，７５０，７６０などの、クライアントシステム上のユーザは、ISP７１０，７１５などのインターネットサービスプロバイダを通じて、インターネットに対するアクセスを得る。インターネットへのアクセスは、クライアントコンピュータシステムのユーザが情報を交換したり、e-mailを送受信したり、HTMLフォーマットで作成された文書などの文書を閲覧したりすることを可能にする。これらの文書は、ウェブサーバ７２０など、インターネット「上」にあると見なされるウェブサーバによって提供されることが多い。これらのウェブサーバは、ISP７１０などのISPによって提供されることが多いが、コンピュータシステムは、それがISPでなくてもセットアップしてインターネットにつなぐことが可能である。
【００３６】
ウェブサーバ７２０は、一般に、サーバコンピュータシステムとして動作する少なくとも１つのコンピュータシステムであり、ワールドワイドウェブのプロトコルによって動作するように構成され、インターネットに結合される。ウェブサーバ７２０は、オプションとして、クライアントシステム用にインターネットへのアクセスを提供するISPの一部であることが可能である。ウェブサーバ７２０は、サーバシステム７２５に結合された状態で図示されており、サーバシステム７２５自体は、メディアデータベースの形態であると見なすことができるウェブコンテンツ７９５に結合される。図７では、２つのコンピュータシステム７２０，７２５が示されているが、ウェブサーバシステム７２０およびサーバコンピュータシステム７２５は、異なるソフトウェアコンポーネント、すなわちウェブサーバ機能を提供するソフトウェアコンポーネントと、サーバコンピュータ一ステム７２５によって提供される後ほど詳述されるサーバ機能を提供するソフトウェアコンポーネントと、を有する１つのコンピュータシステムであることが可能である。
【００３７】
クライアントコンピュータシステム７３０，７４０，７５０，７６０は、それぞれ、ウェブサーバ７２０によって提供されるHTMLページを適切なウェブ閲覧ソフトによって見ることができる。ISP７１０は、クライアントコンピュータシステム７３０の一部であると見なすことが可能なモデムインターフェース７３５を通じて、クライアントコンピュータシステム７３０にインターネット接続性を提供する。クライアントコンピュータシステムは、パソコンシステム、ネットワークコンピュータ、ウェブテレビシステム、またはその他の同様なコンピュータシステムであることが可能である。
【００３８】
同様に、ISP７１５は、クライアントシステム７４０，７５０，７６０のために、インターネット接続性を提供する。ただし、図７に示されるように、これらの接続は、３つのコンピュータシステムについて同一ではない。クライアントコンピュータシステム７４０が、モデムインターフェース７４５を通じて結合される一方で、クライアントコンピュータシステム７５０，７６０は、LANの一部である。図７において、インターフェース７３５，７４５は、概して「モデム」として示されているが、これらの各インターフェースは、アナログモデム、ISDNモデム、ケーブルモデム、衛星伝送インターフェース（例えば「direct PC」）、またはコンピュータシステムをその他のコンピュータシステムに結合するためのその他のインターフェースであることが可能である。
【００３９】
クライアントコンピュータシステム７５０，７６０は、イーサネットネットワークインターフェースまたはその他のネットワークインターフェースであることが可能なネットワークインターフェース７５５，７６５を通じてLAN７７０に結合される。LAN７７０は、また、ローカルエリアネットワークのためのファイアウォールおよびその他のインターネット関連サービスを提供することが可能なゲートウェイコンピュータシステム７７５にも結合される。このゲートウェイコンピュータシステム７７５は、クライアントコンピュータシステム７５０，７６０にインターネット接続性を提供するために、ISP７１５に結合される。ゲートウェイコンピュータシステム７７５は、従来のサーバコンピュータシステムであることが可能である。また、ウェブサーバシステム７２０は、従来のサーバコンピュータシステムであることが可能である。
【００４０】
あるいは、ゲートウェイシステム７７５を通じてインターネットにつなぐ必要なくファイル７９０およびその他のサービスをクライアント７５０，７６０に提供するため、ネットワークインターフェース７８５を通じてLAN７７０にサーバコンピュータシステム７８０を直接結合することが可能である。
【００４１】
図８は、クライアントコンピュータシステムもしくはサーバコンピュータシステムとして、またはウェブサーバシステムとして使用することが可能な従来のコンピュータシステムの一例を示している。このようなコンピュータシステムは、ISP７１０などのインターネットサービスプロバイダの機能の多くを実施するために使用することができる。コンピュータシステム８００は、モデムまたはネットワークインターフェース８２０を通じて外部のシステムに接続する。モデムまたはネットワークインターフェース８２０は、コンピュータシステム８００の一部であると見なせることがわかる。このインターフェース８２０は、アナログモデム、ISDNモデム、ケーブルモデム、トークンリングインターフェース、衛星伝送インターフェース（例えば「direct PC」）、またはコンピュータシステムをその他のコンピュータシステムに結合するためのその他のインターフェースであることが可能である。
【００４２】
コンピュータシステム８００は、インテルのペンティアムマイクロプロセッサまたはモトローラのパワーＰＣマイクロプロセッサなどの従来のマイクロプロセッサであることが可能なプロセッサ８１０を含む。メモリ８４０は、バス８７０によってプロセッサ８１０に結合される。メモリ８４０は、ダイナミックランダムアクセスメモリ（DRAM）であることが可能であり、また、スタティックRAM（SRAM）を含むこともできる。バス８７０は、プロセッサ８１０を、メモリ８４０に、また、不揮発性ストレージ８５０、ディスプレイコントローラ８３０、および入出力（I/O）コントローラ８６０に結合する。
【００４３】
ディスプレイコントローラ８３０は、ブラウン管（CR）または液晶ディスプレイ（LCD）であることが可能なディスプレイデバイス８３５上のディスプレイを、従来の方式で制御することができる。入出力デバイス８５５は、キーボード、ディスクドライブ、プリンタ、スキャナ、およびマウスまたはその他のポインティングデバイスを含むその他の入出力デバイスを含むことができる。ディスプレイコントローラ８３０および入出力コントローラ８６０は、従来の周知の技術によって実装することができる。デジタル画像入力デバイス８６５は、デジタルカメラであることが可能であり、デジタルカメラからの画像をコンピュータシステム８００に入力可能にするために、入出力コントローラ８６０に結合される。
【００４４】
不揮発性ストレージ８５０は、多くの場合、磁気ハードディスク、光ディスク、または大量データ用の別の形態のストレージである。このデータの一部は、コンピュータシステム８００におけるソフトウェアの実行中、直接的なメモリアクセスプロセスによって、メモリ８４０にしばしば書き込まれる。当業者ならば、「マシン読み取り可能な媒体」または「コンピュータ読み取り可能な媒体」という用語が、プロセッサ８１０によってアクセス可能なあらゆるタイプのストレージデバイスを含み、データ信号を符号化する搬送波をも網羅していることを、直ちに認識できるであろう。
【００４５】
コンピュータシステム８００は、様々なアーキテクチャを有する、考えられる多くのコンピュータシステムの一例である。例えば、インテルのマイクロプロセッサに基づくパソコンは、複数のバスを有することが多く、そのうちの１つは、周辺機器用の入出力（I/O）バスであり、１つは、プロセッサ８１０をメモリ８４０に直接つなぐバスである（メモリバスと称されることが多い）。これらのバスは、バスプロトコルの差異ゆえに必要とされるあらゆる変換を実施するブリッジコンポーネントを通じてつなぎ合わされる。
【００４６】
ネットワークコンピュータは、本発明とともに使用することができる別のタイプのコンピュータシステムである。ネットワークコンピュータは、ハードディスクまたはその他のマスストレージを含まないのが通常であり、実行可能なプログラムは、プロセッサ８１０による実行のために、ネットワーク接続からメモリ８４０へと読み込まれる。当該分野で知られているウェブテレビシステムもまた、本発明にしたがったコンピュータシステムであると見なされるが、特定の入力デバイスまたは出力デバイスなど、図８に示された一部の特徴を欠いている可能性がある。典型的なコンピュータシステムは、プロセッサ、メモリ、およびメモリをプロセッサに結合するバスを少なくとも含むのが通常である。
【００４７】
また、コンピュータシステム８００は、ディスクオペレーティングシステムなど、オペレーティングシステムソフトウェアの一部であるファイル管理システムを含む、オペレーティングシステムソフトウェアによって制御される。関連のファイル管理システムソフトウェアをともなうオペレーティングシステムソフトウェアの一例は、ワシントン州レッドモンド所在のマイクロソフトからのWindows（登録商標）として知られるオペレーティングシステムおよび関連のファイル管理システムのシリーズである。関連のファイル管理システムソフトウェアをともなうオペレーティングシステムソフトウェアのもう１つの例は、Linuxオペレーティングシステムおよび関連のファイル管理システムである。ファイル管理システムは、通常、不揮発性ストレージ８５０に格納されており、ファイルを不揮発性ストレージ８５０に格納することを含む、データを入出力するためおよびデータをメモリに格納するためにオペレーティングシステムによって求められる様々な行為をプロセッサ８１０に実行させる。
【００４８】
詳細な説明の一部は、コンピュータメモリ内のデータビットに対する動作のアルゴリズムおよびシンボル表示のかたちで提示される。これらのアルゴリズム的記述および表示は、データ処理の分野の当業者が自身の作業の内容をその他の当業者へと最も効果的に伝えるために使用される手段である。ここでは、そして一般に、アルゴリズムは、所望の結果を導く一連の自己無撞着動作であると考えられる。これらの動作は、物理量の物理的操作を必要とする動作である。必ずしも必要ではないが、これらの量は、通常は、格納、転送、結合、比較、およびその他の操作が可能な電気信号または磁気信号の形態をとる。主として共通使用の理由で、これらの信号は、ときには、ビット、値、要素、シンボル、文字、用語、数などと称すると便利であることがわかっている。
【００４９】
しかしながら、これらのおよび類似の用語は、全て、適切な物理量に関連付けられるべきものであり、これらの量に適用された便利なラベルにすぎないことを、念頭に置いておくべきである。明記されない限り、あるいは以下の議論から明らかでない限り、説明全体を通して、「処理する」、「計算する」、「算出する」、「決定する」、または「表示する」などの用語を用いた議論は、コンピュータシステムのレジスタ内およびメモリ内において物理（電子）量として表されるデータを操作して、これらを、コンピュータシステムのメモリ内、レジスタ内、または同様なその他の情報ストレージ、伝送デバイス、もしくはディスプレイデバイス内においてやはり物理量として表されるその他のデータに変換する、コンピュータシステムまたは類似の電子計算デバイスの行為およびプロセスを意味する。
【００５０】
本明細書において、本発明のいくつかの実施形態は、動作を実施するための装置にも関する。この装置は、所要の目的のために特別に構築されてもよいし、あるいは格納されたコンピュータプログラムによって選択的にアクティブ化されるまたは再構成される汎用コンピュータを含んでもよい。このようなコンピュータプログラムは、フロッピィディスク、光ディスク、CD-ROM、および光磁気ディスクを含むあらゆるタイプのディスク、ならびに読み出し専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、EPROM、EEPROM、磁気カードもしくは光カード、または電子的命令の格納に適したあらゆるタイプの媒体などを含むがこれらに限定されず、それぞれコンピュータシステムバスに結合された、コンピュータ可読ストレージ媒体に格納することができる。
【００５１】
本明細書において提示されるアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたはその他の装置とも本質的に関連付けられない。本明細書の教示内容にしたがったプログラムとともに、各種の汎用システムが使用されてもよいし、あるいは、必要とされる方法のステップを実施するために、より特化された装置を構築すると便利であることがわかる場合もある。これらの様々なシステムに必要とされる構造が、以下の説明から明らかになる。また、本発明は、いかなる特定のプログラミング言語に関連して説明されることもなく、したがって、各種の実施形態は、様々なプログラミング言語を使用して実装することが可能である。
【００５２】
図７および図８に示されたような、各種のネットワークおよびマシンを使用することが可能である。もう１つのタイプのネットワークには、セルラーネットワークがある。
【００５３】
各種タイプのデバイス上において、コードセグメントが実行される。図９は、コードセグメントを実行するプロセスの一実施形態を示している。プロセス９００は、関数呼び出しを受信すること、関数を動作させること、および結果を戻すことを含む。先ず、モジュール９１０において、関数が呼び出される。関数が参照されている間は、その他のコード遷移も適切であり、戻り結果またはパラメータをともなってもともなわなくてもよい。一般に、いくつかの信号は、たとえ結果が戻されない場合でも、コードセグメントの実行の終了を示す。モジュール９２０では、関数またはコードセグメントが実行される。モジュール９３０では、関数またはコードセグメントの結果が戻される、あるいは呼び出しコードセグメントまたはプロセスに伝えられる。
【００５４】
コードセグメントとともに防護層が使用される場合は、防護層によってプロセスを認証することができる。図１０は、コードセグメントを実行するプロセスの代替の一実施形態を示している。プロセス１０００は、コードセグメントとの防護層の併用を示している。プロセス１０００は、関数呼び出しを受信すること、呼び出しを検証すること、呼び出しを内部に引き渡すこと、関数を動作させること、内部結果を戻すこと、および結果を外部に戻すことを含む。
【００５５】
プロセス１０００は、モジュール１０１０において、関数呼び出しの受信、またはコードセグメントのその他のアクティブ化からスタートする。関数呼び出しは、モジュール１０２０において、関連の防護スタックを通じてなどによって検証される。関数呼び出しは、次いで、モジュール１０３０において、内部的にコードセグメントへと引き渡される。関数は、次いで、モジュール１０４０において動作または実行され、結果、状態変化、または何らかの種類の副作用を生成する。モジュール１０５０において、結果は、例えばコードセグメントから防護層または類似のラッパーへなどのように、内部的に戻される。ラッパーは、次いで、モジュール１０６０において、関数の結果を戻す。
【００５６】
認証プロセスの様々な実施形態が使用可能である。
【００５７】
図１１は、コードセグメントを検証するプロセスの一実施形態を示している。プロセス１１００は、コードセグメントを動作させてプロセスを検証するプロセスの代替の一実施形態を示している。プロセス１１００は、関数呼び出しを受信すること、関数呼び出しをチェックすること、呼び出しを内部へと引き渡すこと、関数を動作させること、防護スタックに関連して追加の関数を呼び出すこと、第２の関数からの戻りを受信すること、結果を戻すことと、を含む。
【００５８】
モジュール１１０５において、関数の呼び出しまたは類似のコード遷移が受信される。例示のため、この実施形態は、関数の呼び出しに関して説明される。モジュール１１１０では、防護スタックが、適切な情報についてチェックされる。これは、呼び出しの適切な発信元アドレスについてチェックするなど単純であってもよいし、あるいはより複雑であってもよい。モジュール１１１５では、コード遷移の引数もまた、検証済みであるかどうかをチェックされる。モジュール１１２０において、関数の呼び出しは、内部関数に引き渡される。モジュール１１２５では、内部関数が実行される。
【００５９】
モジュール１１３０では、ネスト関数の呼び出しが必要であるか否かに関する決定がなされる。もし必要であれば、モジュール１１４０において、本（内部）関数は、防護スタック上のデータをプッシュする。モジュール１１４５では、次の関数が呼び出される。モジュール１１５０では、次の関数からの戻り結果が受信される。モジュール１１５５では、防護スタックが、適切な情報（例えば本関数からの未変更データ、または本関数からの検証済みデータなど）についてチェックされる。モジュール１１６０において、防護層はポップされ、本関数に関連する情報を防護スタックから除外する。
【００６０】
最終的に、本（内部）関数は、結果を戻す。これは、モジュール１１７０において生じる。この結果は、次いで、モジュール１１８０において、関数を呼び出したコードセグメントへと防護層によって戻される。こうして、関数の目的全体が達成される。なお、ネスト関数またはその他のコードセグメントなど呼び出しを受けたものは、いずれも類似のプロセスをたどるのが通常であることに留意せよ。
【００６１】
コードタンブラによって、認証を増強することが可能である。これらは、基本的に、その他のモジュールへとクロスするが任意の順序で完了することができるコード動作である。一群のモジュールに対する呼び出しは、ランダムに順序付けることが可能である。これは、より多くのタンブラを追加するために、何度かつなぎあわせることができるので、より大きなロックの場合は、複数のタンブラの組み合わせとなり、真のコードのみが、その厳密な組み合わせによってプログラムされている。防護スタックの検査は、これらのモジュールの実行の形跡を見つけ、次いで、認証の発生後にこれらの形跡を除去することができる。しかしながら、コードタンブラに関連したモジュールをばらばらの順序で実行すると、防護スタック上に異なる形跡のセットが残され、これは、認証が失敗するべきであることを示す。コードタンブラモジュールのセットに対する呼び出しの一例は、次の通りである。
【００６２】
module foo
calls module bar
module bar
calls module bar_corge
calls module bar_grault
calls module bar_waldo
calls module baz
calls module qux
【００６３】
基本的に、bar、baz、quxに対する呼び出しは、ランダムに順序付けることができる。しかしながら、前述のように、これは、より多くのタンブラを追加するために、何度かつなぎあわせることができる。したがって、たとえ何者かが他の防御層を突破した場合でも、コードタンブラは、性能に対する影響を比較的最小に抑えつつ、打ち負かすための別の層を提供する。
【００６４】
ワームは永続的であるので、たとえ様々な層によって次々に攻撃をかわしても、いくらかの時間が経過すると、ワームが防護層をすり抜ける可能性がある。この統計的攻撃に反撃するため、どのモジュールがデバイスに到る本来のセキュリティホールであったかを決定することができる。オペレーションシステムは、攻撃に成功したのがどのソケットであるか、したがってどの起点IPアドレス／ポートであるか、そしてデバイス上のどのポート／サービスであるかを知ることができる。システムは、すると、所定の方針に基づいて、そのIPアドレスからの全てのトラフィックまたはそのポートへの全てのトラフィックをブロックすることができる。このような方針は、例えば１回の攻撃後にトリガするなど、極めてパラノイドであってもよいし、あるいは、例えば一定の数のアドレスから所定の閾値回数の試みがあった後にトリガするように設定されてもよい。ワームは、多数のポイントから同時に攻撃することができるので、このような閾値は、とりわけ有効であると考えられる。また、攻撃の回数に勝るその他の基準を使用することも可能である。
【００６５】
防護層をともなうパッチは、様々なタイプの媒体に組み込むことが可能である。図１２は、パッチを組み込んだ媒体の一実施形態を示している。FLASHメモリが図示されている。その他の実施形態では、その他の媒体も適している。メモリ１２００は、コードセグメント：foo、bar、およびgrokを含む。これらの各コードセグメントは、関数を提供すること、および関連の防護層を有することを予期される。したがって、セグメント１２１０は、foo()コードを提供し、セグメント１２２０は、foo()のための防護層を提供する。同様に、セグメント１２３０は、bar()コードを提供し、セグメント１２４０は、bar()のための防護層を提供する。更に、セグメント１２５０は、grok()コードを提供し、セグメント１２６０は、grok()のための防護層を提供する。同様のコード構成は、１つまたは複数の媒体のその他の実施形態でも使用することが可能である。
【００６６】
図に示されたラッパーは、防護層を提供することができるが、ハッカーは、自身による偽のラッパーを追加することによって、ラッパーの選別を迂回しようと試みる。二次スタックのためのラッパーが追加されると、ハッカーは、どのようにすればそのコードをリアルタイムで飛び越えられるかを突き止めるために、ラッパーコードをのぞき見ようと試みる、あるいは単純に、ハードワイヤードアドレスを使用しようと試みる。この種の、壁を飛び越える攻撃を阻止するため、各ラッパー関数は、ラッパーコードの先頭に、ジャンクコードを有することができる。このジャンクコードは、任意の自動化ワームがAPIの真のかつ正しい本来のアドレスを嗅ぎつける試みを混乱させるため、長さがランダムでありなおかつ結果がランダムである。したがって、例えば、セグメント１２２０は、攻撃を混乱させるために先頭に追加された、ランダムなコードセットを有することが可能である。単純なハードワイヤードジャンプを阻止するため、モジュールの順序もまた、ランダムであることが可能である。したがって、セグメント１２１０，１２２０，１２３０，１２４０，１２５０，１２６０は、アドレスの内部的一貫性をともなうように、ただしコードエントリポイントの存在する場所では最初の検査に基づいてそれが明らかにならないように、ランダムな順序で格納することが可能である。
【００６７】
同様に、パッチは、様々な方法で適用することが可能である。図１３は、パッチを適用するプロセスの一実施形態を示してる。プロセス１３００は、入手可能なパッチをデバイスに通知することと、パッチをデバイスに送信することと、デバイスにおいてパッチを抽出することと、パッチを適用することとを含む。プロセス１３００は、例えば、ネットワーク内にあるまたはデバイスに結合された、サーバノードまたは制御ノードにおいて実装することが可能である。デバイスは、モジュール１３１０において、入手可能なパッチを通知される。これは、例えば、デバイスにメッセージを送信することをともなう。モジュール１３２０では、デバイスにパッチが送信される。モジュール１３３０では、（デバイスにおいて）パッチが抽出される。これは、例えば、パットが信頼のおけるソースからのものであることを確認するための、認証データ用のトランザクションをともなうことが可能である。パッチは、次いで、モジュール１３４０において適用される。
【００６８】
更に、１つまたは複数のパッチは、システム全体によって管理することが可能である。図１４は、パッチ管理のためのシステムの一実施形態を示している。システム１４００は、パッチ管理コンソールと、関連のパッチと、ユーザプロフィールと、全体ディレクティブと、配布インターフェースと、パッチを受信するための様々なデバイスとを提供する。
【００６９】
パッチ管理コンソール１４２０は、様々なパッチ１４１０と連携しており、各パッチ１４１０は、その中の様々なコードセグメントのための防護層を内包している。ディレクティブ１４３０のセットは、パッチ１４１０がコンソール１４２０によってどのように配布されるべきであるかに関する全体的枠組みを提供する。ディレクティブ１４３０は、例えば、規則のセットとして表すことが可能である。コンソール１４２０は、また、使用可能なユーザデータ１４４０を有しており、これは、特定のデバイスまたはユーザを全体ディレクティブ１４３０に整合させることを可能にする。コンソール１４２０は、それらのユーザまたはデバイスに適用される規則にしたがってパッチを配布するために、配布インターフェース１４５０を使用する。こうして、デバイス１４６０，１４７０，１４８０は、次いで、パッチを受信することができる。
【００７０】
コンソール１４２０は、特定のパッチ１４１０を特定のユーザにのみ、または特定のデバイスにのみ配布するように指示される。更に、コンソール１４２０は、例えばデバイスが断続的にのみネットワークにつながれる場合などに、パッチの配布がどのように進行しているかを（ユーザが）監視するために使用することができる。また、コンソール１４２０は、必要に応じてディレクティブ１４３０またはユーザデータ１４４０を変更するために使用することができる。
【００７１】
ソフトウェア内のセキュリティを維持するためのもう１つのオプションは、ソフトウェアの動作を追跡することに関する。これは、ソフトウェアの動作時にそのソフトウェアにマークを記すことによって、プログラムまたはモジュールが所定の時点でコードのどこにあるかに関する情報を提供することができる。これらのマークは、次いで、そのコードが予期せぬ領域に逸れていそうである（マルウェアなどの外部コードの存在を示している）かを決定するために観察され、ソフトウェアの正常動作と比較される。コードによって作成されたマークは、一連の音符として読み出すことができ、そして、そのコードが予期されるメロディを演奏している（正しく動作している）か、あるいか何らかの理由でコードが音程の狂ったもしくはリズムのずれた演奏をしている（マルウェアを示唆している）かを決定するために、類似の一連の音符と比較することができる。
【００７２】
図１５は、コードの進行を追跡するために使用することができる循環バッファの一実施形態を示している。バッファ１５００は、データ構造の配列を表している。各データ構造は、プロセスの状態に関する情報を含むことができる。ポインタをバッファ１５００内の第１のエントリに置くと、バッファ１５００を循環型で使用することが可能になる。循環バッファ１５００の長さは、コード動作が解析されている深さ（履歴がどこまで遡るか）を決定するために制御可能であることに留意せよ。
【００７３】
様々なデータ構造が、バッファ１５００とともに使用することができる。図１６は、コードの進行を追跡するために使用することができるエントリのデータ構造の一実施形態を示している。データ構造１６００は、位置１６１０、プロセスID１６２０、およびタイムスタンプ１６３０を格納するためのフィールドを提供する。したがって、データ構造１６００は、ルーチン内にマークまたはポインタを提供し、プロセスが所定の時間にモジュールのコードのどこにあったかを示すことができる。いくつかの実施形態では、プログラムカウンタまたは類似の値、タイムスタンプ、およびプロセス識別子を循環バッファ内のデータ構造１６００に記録するマークルーチンに対する呼び出しを、コードに植え付けることができる。
【００７４】
図１６のデータ構造は、単一のバッファ内においてコードを追跡するのに有用であるが、複数のコンテキストを跨いでコードを追跡する、または異なるモジュールを並行して追跡する必要があることもある。図１７は、コードの進行を追跡するのに使用することができる循環バッファのセットの一実施形態を示している。セット１７００は、２つのバッファ１７１０，１７２０を含むものとして図示され、各バッファは、データ構造１６００のようなデータ構造で構成することができる。一実施形態において、バッファ１７１０は、第１のコンテキスト（例えばオペレーティングシステム）内においてコードを追跡するために使用され、バッファ１７２０は、第２のコンテキスト（例えばアプリケーション）内においてコードを追跡するために使用される。
【００７５】
循環バッファを配置したら、次は、コードの動作を基準と比較する必要がある。図１８は、ソフトウェアコードのグラフの一実施形態を示している。グラフは、ソフトウェアがとりうる全ての経路（またはソフトウェアが合法的にとりうる全ての経路）を提供する。これは、シミュレーションまたはテストケースを使用してソフトウェアを走らせることによって、あるいはコンパイルおよびリンケージがソフトウェアを解析するのと同じ手法でソフトウェアを解析することによって、作成することができる。
【００７６】
したがって、グラフ１８００は、ルーチンＡ，Ｂ，Ｃ，Ｄを使用したプログラムまたはモジュールのグラフを示している。グラフの各ノードは、ルーチン内のマークポイント、すなわちマーク手順／関数呼び出しが挿入されたポイントを表している。グラフの辺は、許容可能な遷移を表している。したがって、循環バッファ１５００のコンテンツによって指示されたとおりにグラフ１８００を横切って、タイムスタンプの差分を、予期されるノード間の差分と比較する試みをなすことが可能である。もし時間差が大きすぎる、または小さすぎるようであれば、これは、エラーを意味することができる。なお、実施形態によっては、時間差に対する許容範囲をグラフ１８００に含ませる、あるいは許容範囲を事前に決定することが可能であることに留意せよ。もし、グラフ１８００に基づいて、バッファ１５００内の遷移が許容されなかった場合は、これは、別のタイプのエラーを意味する。
【００７７】
グラフ１８００は、場合によっては、デバイス上において局所的に生成することができる。これは、アップデートされたソフトウェアを考慮することを可能にする。あるいは、グラフ１８００は、ソフトウェア開発プロセスの一部として生成することができる。このような場合は、アップデート中またはアップデート後のグラフ生成において、ローカルデバイスリソースは不要である。
【００７８】
マークを生じさせて比較を行うプロセスは、様々な方法で実装することができる。図１９は、循環バッファを使用してコードを追跡するプロセスの一実施形態を示している。プロセス１９００は、マーク（呼び出し）を受信すること、情報にマークを記すこと、素早いチェックを実施すること、プロセスがＯＫであるかを決定すること、マークがクリティカルであるかを決定すること、総チェックを実施すること、および必要に応じてエラーをシグナル通知することを含む。
【００７９】
モジュール１９１０では、ルーチンからのマーク関数呼び出しなどを通じてマークが受信される。モジュール１９２０では、マーク情報が記録される。モジュール１９３０では、マークが妥当であるかを決定するために、素早いチェックがなされる。これは、マークおよび先行するマークをグラフに照らしてチェックするなどのように単純であってもよいし、あるいはもっと複雑であってもよい。例えば、モジュール１９３０は、タイマ１９９０（例えばシステムクロックまたは個別のタイマなど）を使用することができる。もしプロセスが正常に動作している場合は、モジュール１９４０において、先に進む決定がなされる。もしそうでない場合は、モジュール１９５０において、エラーがシグナル通知される。
【００８０】
マークがクリティカルマークであるかが、モジュール１９６０において決定される。クリティカルマークは、マーク関数呼び出し内のパラメータによって示すことができる、あるいは例えば登録されているマークの所定の数に基づくことが可能である。もしマークがクリティカルである場合は、モジュール１９７０において、総チェックを実施することができる。総チェックは、例えば、単に遷移を見るのではなく、グラフに照らして記された（記録された）全パラメータを評価することを含むことができる。もしモジュール１９８０において、プロセスが、許容範囲を超えた時間または非合法的な遷移を示していると決定された場合は、モジュール１９５０において、エラーがシグナル通知される。もしモジュール１９６０または１９８０において、プロセスがＯＫである場合は、プロセスは、次のマークのためにモジュール１９１０に戻る。
【００８１】
ソフトウェアが動的に変化する場合は、このようなシステムのために、グラフを作成および維持することが重要になる。図２０は、ソフトウェアコードのグラフを維持および使用するプロセスの一実施形態を示している。プロセス２０００は、ソフトウェアを作成すること、関連のグラフを作成すること、ソフトウェアを動作させること、ソフトウェアをアップデートすること、およびグラフをアップデートすることを含む。
【００８２】
プロセス２０００は、モジュール２０１０において、ソフトウェアを作成することから開始する。ソフトウェアが作成された（例えばプログラムされた）後は、モジュール２０２０において、グラフが作成される。グラフは、シミュレーション、ソフトウェア品質保証、またはソフトウェアの自動解析を通じて作成することができる。モジュール２０３０において、ソフトウェアは、例えばカスタマなどによって動作される。これは、モジュール２０２０のグラフに照らしてマークを記す、およびチェックすることを含む。モジュール２０４０では、ソフトウェアに対するアップデートが伝搬され受信される。これは、モジュール２０５０において提供される、（一般に）相応にアップデートされたグラフをともなう。したがって、ソフトウェアは、一貫性チェックおよびマルウェアに対抗するセキュリティをなおも可能にしつつ、変化に適応することができる。
【００８３】
以上からわかるように、本明細書では、例示のために本発明の具体的な実施形態が説明されてきたが、本発明の趣旨および範囲から逸脱することなしに、様々な変更が可能である。例えば、様々なまたはいくつかの実施形態で存在すると考えられる特性について言及されてきたが、これらの特性は、必ずしも本発明の趣旨および範囲を限定するものではない。例示および説明では、本発明の趣旨および範囲のなかでその他のかたちで形成または組み合わせることができる構造が提供されている。更に、一般に、１つの実施形態からの特徴は、それらの特徴が何らかのかたちで互いに排他的でない限り、本文書において言及されたその他の実施形態とともに使用することができる。
【００８４】
具体的に言うと、各種ブロック図の個々のモジュールは、方法または装置の機能的モジュールを表しており、必ずしも、本発明の趣旨および範囲に固有の物理的もしくは論理的分離または動作順序を示すものではない。同様に、方法は、線形プロセスとして例示され説明されているが、このような方法は、本発明の趣旨および範囲のなかで順序付けられたまたは並行して実装された動作を有することが可能である。
【図面の簡単な説明】
【００８５】
【図１】コードモジュールの一実施形態を例示した図である。
【図２】コードAPIの一実施形態を例示した図である。
【図３】コードモジュールの代替の一実施形態を例示した図である。
【図４】コードAPIの代替の一実施形態を例示した図である。
【図５】コードセグメントのシステムの一実施形態を例示した図である。
【図６】コードセグメントのシステムの代替の一実施形態を例示した図である。
【図７】マシンネットワークの一実施形態を例示した図である。
【図８】マシンまたはコンピュータの一実施形態を例示した図である。
【図９】コードセグメントを実行するプロセスの一実施形態を例示した図である。
【図１０】コードセグメントを実行するプロセスの代替の一実施形態を例示した図である。
【図１１】コードセグメントを検証するプロセスの一実施形態を例示した図である。
【図１２】パッチを組み入れた媒体の一実施形態を例示した図である。
【図１３】パッチを適用するプロセスの一実施形態を例示した図である。
【図１４】パッチ管理のためのシステムの一実施形態を例示した図である。
【図１５】コードの進行を追跡するために使用することができる循環バッファの一実施形態を例示した図である。
【図１６】コードの進行を追跡するために使用することができるエントリのデータ構造の一実施形態を例示した図である。
【図１７】コードの進行を追跡するために使用することができる循環バッファのセットの一実施形態を例示した図である。
【図１８】ソフトウェアコードのグラフの一実施形態を例示した図である。
【図１９】循環バッファを使用してコードを追跡するプロセスの一実施形態を例示した図である。
【図２０】ソフトウェアコードのグラフを維持および使用するプロセスの一実施形態を例示した図である。
【図１】
2009509273.tif 000003
【図２】
2009509273.tif 000004
【図３】
2009509273.tif 000005
【図４】
2009509273.tif 000006
【図５】
2009509273.tif 000007
【図６】
2009509273.tif 000008
【図７】
2009509273.tif 000009
【図８】
2009509273.tif 000010
【図９】
2009509273.tif 000011
【図１０】
2009509273.tif 000012
【図１１】
2009509273.tif 000013
【図１２】
2009509273.tif 000014
【図１３】
2009509273.tif 000015
【図１４】
2009509273.tif 000016
【図１５】
2009509273.tif 000017
【図１６】
2009509273.tif 000018
【図１７】
2009509273.tif 000019
【図１８】
2009509273.tif 000020
【図１９】
2009509273.tif 000021
【図２０】
2009509273.tif 000022
【国際調査報告】
2009509273.tif 000023