(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-19
(45)【発行日】2024-06-27
(54)【発明の名称】ファームウェアのアンチロールバック
(51)【国際特許分類】
G06F 21/57 20130101AFI20240620BHJP
G06F 9/4401 20180101ALI20240620BHJP
【ＦＩ】
G06F21/57 350
G06F9/4401
【請求項の数】
15
(21)【出願番号】P 2021571836
(86)(22)【出願日】2020-06-18
(65)【公表番号】
(43)【公表日】2022-08-29
(86)【国際出願番号】 IB2020000490
(87)【国際公開番号】W WO2021001683
(87)【国際公開日】2021-01-07
【審査請求日】2023-06-01
(31)【優先権主張番号】16/502,733
(32)【優先日】2019-07-03
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】508301087
【氏名又は名称】エーティーアイ・テクノロジーズ・ユーエルシー
【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ
【住所又は居所原語表記】Ｏｎｅ Ｃｏｍｍｅｒｃｅ Ｖａｌｌｅｙ Ｄｒｉｖｅ Ｅａｓｔ， Ｍａｒｋｈａｍ， Ｏｎｔａｒｉｏ， Ｌ３Ｔ ７Ｘ６ Ｃａｎａｄａ
(74)【代理人】
【識別番号】100108833
【弁理士】
【氏名又は名称】早川 裕司
(74)【代理人】
【識別番号】100111615
【弁理士】
【氏名又は名称】佐野 良太
(74)【代理人】
【識別番号】100162156
【弁理士】
【氏名又は名称】村雨 圭介
(72)【発明者】
【氏名】カシャカマナサン ナダラジャ
(72)【発明者】
【氏名】ベネディクト チェン
【審査官】田中 啓介
(56)【参考文献】
【文献】特開２０１７－２１４３４（ＪＰ，Ａ）
【文献】特表２０１５－５３３４４４（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１４／０２５０２９０（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ８／００－８／３８
Ｇ０６Ｆ８／６０－８／７７
Ｇ０６Ｆ９／４４－９／４４５、９／４５１
Ｇ０６Ｆ２１／１２－２１／１６
Ｇ０６Ｆ２１／５０－２１／５７
Ｇ０９Ｃ１／００－５／００
Ｈ０４Ｋ１／００－３／００
Ｈ０４Ｌ９／００－９／４０
(57)【特許請求の範囲】
【請求項1】
コンピューティングプラットフォームのファームウェアを検証する方法であって、セキュリティプロセッサをブートすることと、
前記セキュリティプロセッサにおいて、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得することと、
前記セキュリティプロセッサにおいて、ファームウェアセキュリティテーブルのテーブルＳＰＬが前記最小ＳＰＬ以上であることを検証することであって、前記ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む、ことと、
ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得することと、（ｂ）前記ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得することと、（ｃ）前記各ファームウェアＳＰＬ値が前記各チェックＳＰＬ値以上であるかどうかをチェックすることと、によって、複数のファームウェアコードモジュールを検証することと、を含む、
方法。
【請求項2】
前記複数のファームウェアコードモジュールを検証する前に、ブートローダＳＰＬ値を含むブートローダにアクセスして、前記ブートローダＳＰＬ値が、前記ファームウェアセキュリティテーブルに記憶された関連するブートローダチェックＳＰＬ値以上であるかどうかをチェックすることと、前記ブートローダＳＰＬ値が関連するブートローダチェックＳＰＬ値以上である場合に、前記ブートローダを前記セキュリティプロセッサにロードし、前記ブートローダを実行することと、
前記ブートローダＳＰＬ値が関連するブートローダチェックＳＰＬ値以上でない場合に、リカバリ手順を行うことと、をさらに含み、
前記ブートローダは、前記複数のファームウェアコードモジュールの検証を行う、
請求項１の方法。
【請求項3】
前記ブートローダを前記セキュリティプロセッサにロードすることは、不揮発性メモリからロードすることを含む、請求項２の方法。
【請求項4】
前記セキュリティプロセッサをブートすることは、前記セキュリティプロセッサに統合されたセキュアリードオンリメモリ（ＲＯＭ）からブートすることを含む、請求項１の方法。
【請求項5】
前記ファームウェアセキュリティテーブルから前記セキュリティプロセッサのランダムアクセスメモリ（ＲＡＭ）にデータをロードすることと、前記複数のファームウェアコードモジュールを検証する場合に、ロードされた前記データにアクセスすることと、をさらに含む、
請求項１の方法。
【請求項6】
前記ファームウェアセキュリティテーブルをアップデートすることと、前記ファームウェアセキュリティテーブルをアップデートすることに関連して、前記テーブルＳＰＬを増加させ、新しい最小ＳＰＬ値を前記ライトワンスメモリビットのセットに書き込むことと、をさらに含む、請求項１の方法。
【請求項7】
前記複数のファームウェアコードモジュールのうち選択されたファームウェアコードモジュールを検証した後に、前記セキュリティプロセッサの制御下で、選択されたファームウェアコードモジュールをプロセッサにロードし、前記プロセッサを初期化することをさらに含む、請求項１の方法。
【請求項8】
前記ライトワンスメモリビットのセットを読み取ることは、ワンタイムプログラマブルヒューズのセットを読み取ることを含む、請求項１の方法。
【請求項9】
セキュリティプロセッサであって、
マイクロコントローラコアと、
前記マイクロコントローラコアに結合されたライトワンスメモリビットのセットと、
前記マイクロコントローラコアに結合されたランダムアクセスメモリ（ＲＡＭ）と、を備え、
前記セキュリティプロセッサは、
前記セキュリティプロセッサをブートすることと、
前記ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得することと、
ファームウェアセキュリティテーブルのテーブルＳＰＬが前記最小ＳＰＬ以上であることを検証することであって、前記ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む、ことと、
ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得することと、（ｂ）前記ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得することと、（ｃ）前記各ファームウェアＳＰＬ値が前記各チェックＳＰＬ値以上であるかどうかをチェックすることと、によって、複数のファームウェアコードモジュールを検証することと、
を行うように動作する、
セキュリティプロセッサ。
【請求項10】
前記セキュリティプロセッサは、前記複数のファームウェアコードモジュールを検証する前に、ブートローダＳＰＬ値を含むブートローダにアクセスして、前記ブートローダＳＰＬ値が、前記ファームウェアセキュリティテーブルに記憶された関連するブートローダチェックＳＰＬ値以上であるかどうかをチェックすることと、
前記ブートローダＳＰＬ値が関連するブートローダチェックＳＰＬ値以上である場合に、前記ブートローダを前記セキュリティプロセッサにロードし、前記ブートローダを実行することと、
前記ブートローダＳＰＬ値が関連するブートローダチェックＳＰＬ値以上でない場合に、リカバリ手順を行うことと、
を行うように動作し、
前記ブートローダは、前記複数のファームウェアコードモジュールの検証を行う、
請求項９のセキュリティプロセッサ。
【請求項11】
前記ブートローダを前記セキュリティプロセッサにロードすることは、不揮発性メモリからロードすることを含む、請求項１０のセキュリティプロセッサ。
【請求項12】
前記不揮発性メモリは、前記セキュリティプロセッサの外部にある、
請求項１１のセキュリティプロセッサ。
【請求項13】
前記セキュリティプロセッサに結合されたセキュアリードオンリメモリ（ＲＯＭ）を備え、
前記セキュリティプロセッサをブートすることは、前記セキュアＲＯＭからブートすることを含む、
請求項１０のセキュリティプロセッサ。
【請求項14】
前記セキュリティプロセッサは、前記ファームウェアセキュリティテーブルへのアップデートを検出することと、前記ファームウェアセキュリティテーブルのアップデートに関連して、前記テーブルＳＰＬを増加させ、新しい最小ＳＰＬ値を前記ライトワンスメモリビットのセットに書き込むことと、を行うように動作する、請求項１０のセキュリティプロセッサ。
【請求項15】
不揮発性メモリと、
前記不揮発性メモリに結合されたシステムオンチップと、を備えるデータ処理プラットフォームであって、
前記システムオンチップは、
１つ以上の処理コアを含むプロセッサと、
マイクロコントローラコアと、前記マイクロコントローラコアに結合されたライトワンスメモリビットのセットと、前記マイクロコントローラコアに結合されたランダムアクセスメモリ（ＲＡＭ）と、前記マイクロコントローラコアに結合されたセキュアブートリードオンリメモリ（ＲＯＭ）と、を含むセキュリティプロセッサと、を備え、
前記セキュリティプロセッサは、
前記セキュリティプロセッサをブートすることと、
前記ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得することと、
ファームウェアセキュリティテーブルのテーブルＳＰＬが前記最小ＳＰＬ以上であることを検証することであって、前記ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む、ことと、
ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得することと、（ｂ）前記ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得することと、（ｃ）前記各ファームウェアＳＰＬ値が前記各チェックＳＰＬ値以上であるかどうかをチェックすることと、によって、複数のファームウェアコードモジュールを検証することと、
を行うように動作する、
データ処理プラットフォーム。
【発明の詳細な説明】
【背景技術】
【0001】
新しいコンピュータ製品のファームウェアがリリースされると、製品の起動後に脆弱性が発見されることがある。脆弱性が発見されると、可能であれば、ハードウェア、ファームウェア及び／又はソフトウェアのアップデートによって脆弱性を軽減することができる。このようなケースでは、脆弱性が重大であり、ソフトウェア又はファームウェアによって対処可能である場合、脆弱であると見なされるソフトウェア又はファームウェアのバージョンがシステムで実行されないように、取り消しメカニズム（revocation mechanism）を実装することが望ましい。このようなケースでは、機能を維持するために、ソフトウェア又はファームウェアのインフィールドアップグレード（in-field upgrade）を行う必要がある。
【0002】
ファームウェアアップグレードのセキュリティを管理するために、ファームウェアのアンチロールバック機能が開発された。一部のアンチロールバック機能は、ワンタイムプログラマブルヒューズ（one time programmable fuses）等のライトワンスメモリビット（write-once memory bits）を使用して、特定のファームウェアの許可バージョン番号を追跡する。しかしながら、通常、これらの解決ソリューションに利用可能なワンタイムプログラマブルヒューズの数は限定されている。さらに、これらの解決ソリューションは、複雑なコンピューティングプラットフォームで生じるファームウェアアップデートの数が原因で、必要となるライトワンスメモリビットの数が増大する。
【図面の簡単な説明】
【0003】
【図1】いくつかの実施形態による、アンチロールバックセキュリティ機能を含むアクセラレーテッドプロセッシングユニット（ＡＰＵ）のブロック図である。
【図2】いくつかの実施形態による、ＰＳＰのより詳細なブロック図である。
【図3】いくつかの実施形態による、ファームウェアを検証及びロードするプロセスを示すフローである。
【図4】いくつかの実施形態による、ファームウェア及びソフトウェアを検証及びロードする別のプロセスを示すフロー図である。
【図5】いくつかの実施形態による、ファームウェアセキュリティテーブル（ＦＳＴ）を示す図である。
【図6】いくつかの実施形態による、ファームウェアモジュールを示す図である。
【発明を実施するための形態】
【0004】
以下の説明において、異なる図面において同じ符号を使用することは、類似又は同一のアイテムを示す。特に断りの無い限り、「結合される（coupled）」という用語及びその関連する動詞の形態は、本技術分野において周知の手段による直接接続及び間接電気接続の両方を含み、特に断りの無い限り、直接接続という記載は、適切な形態の間接電気接続を使用した代替的な実施形態を意味する。
【0005】
方法は、コンピューティングプラットフォームのファームウェアを検証する。方法は、セキュリティプロセッサをブートすることと、セキュリティプロセッサにおいて、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得することと、を含む。方法は、ファームウェアセキュリティテーブルのテーブルＳＰＬが最小ＳＰＬ以上であることを検証し、ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、ファームウェア識別子の各々に関連付けられた複数のチェックＳＰＬ値と、を含む。また、方法は、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が各チェックＳＰＬ値以上であるかどうかをチェックすることによって、複数のファームウェアコードモジュールを検証する。
【0006】
データ処理プラットフォームは、不揮発性メモリと、不揮発性メモリに結合されたシステムオンチップと、を含む。システムオンチップは、１つ以上の処理コアを有するプロセッサと、マイクロコントローラコアを含むセキュリティプロセッサと、マイクロコントローラコアに結合されたライトワンスメモリビットのセットと、マイクロコントローラコアに結合されたランダムアクセスメモリ（ＲＡＭ）と、マイクロコントローラコアに結合されたセキュアブートリードオンリメモリ（ＲＯＭ）と、を備える。セキュリティプロセッサは、セキュリティプロセッサをブートし、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得するように動作する。セキュリティプロセッサは、ファームウェアセキュリティテーブルのテーブルＳＰＬが最小ＳＰＬ以上であることを検証し、ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む。また、セキュリティプロセッサは、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が各チェックＳＰＬ値以上であるかどうかをチェックすることによって、複数のファームウェアコードモジュールを検証する。
【0007】
セキュリティプロセッサは、マイクロコントローラコアと、マイクロコントローラコアに結合されたライトワンスメモリビットのセットと、マイクロコントローラコアに結合されたＲＡＭと、マイクロコントローラコアに結合されたセキュアブートＲＯＭと、を備える。セキュリティプロセッサは、セキュリティプロセッサをブートし、ライトワンスメモリビットのセットを読み取って、最小ＳＰＬを取得するように動作する。セキュリティプロセッサは、ファームウェアセキュリティテーブルのテーブルＳＰＬが最小ＳＰＬ以上であることを検証し、ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む。また、セキュリティプロセッサは、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が各チェックＳＰＬ値以上であるかどうかをチェックすることによって、複数のファームウェアコードモジュールを検証する。
【0008】
１つ以上の有形の非一時的なコンピュータ可読記憶媒体は、セキュリティプロセッサによって実行可能な命令を含むプログラム製品を保持する。命令は、セキュリティプロセッサをブートし、セキュリティプロセッサにおいて、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得するために実行可能である。命令は、ファームウェアセキュリティテーブルのテーブルＳＰＬが最小ＳＰＬ以上であることを検証するためにさらに実行可能であり、ファームウェアセキュリティテーブルは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む。命令は、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ファームウェアセキュリティテーブルにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が、各チェックＳＰＬ値以上であるかどうかをチェックすることによって、複数のファームウェアコードモジュールを検証するためにさらに実行可能である。
【0009】
図１は、いくつかの実施形態による、アンチロールバックセキュリティ機能を含むアクセラレーテッドプロセッシングユニット（ＡＰＵ）１００のブロック図である。ＡＰＵ１００は、様々なホストデータ処理プラットフォームの一部であってもよいシステムオンチップ（ＳｏＣ）として実装される。本実施形態では、ＡＰＵが示されているが、中央処理装置（ＣＰＵ）又はグラフィックスプロセッシングユニット（ＧＰＵ）等の他のデータ処理プラットフォームが使用されてもよい。ＡＰＵ１００は、一般的に、ＣＰＵコアコンプレックス１１０と、グラフィックスコア１２０と、ディスプレイエンジン１３０のセットと、メモリ管理ハブ１４０と、データファブリック１５０と、周辺機器コントローラ１６０のセットと、周辺機器バスコントローラ１７０のセットと、システム管理ユニット（ＳＭＵ）１８０と、プラットフォームセキュリティプロセッサ（ＰＳＰ）２１０と、フラッシュメモリ２２０と、メモリコントローラ１９０のセットと、を備える。
【0010】
ＣＰＵコアコンプレックス１１０は、ＣＰＵコア１１２とＣＰＵコア１１４とを含む。この例においては、ＣＰＵコアコンプレックス１１０は、２つのＣＰＵコアを含むが、他の実施形態においては、ＣＰＵコアコンプレックス１１０は、任意の数のＣＰＵコアを含むことができる。ＣＰＵコア１１２，１１４の各々は、制御ファブリックを構成するシステム管理ネットワーク（ＳＭＮ）１４５と、データファブリック１５０と、に双方向接続されており、メモリアクセス要求をデータファブリック１５０に提供することができる。ＣＰＵコア１１２，１１４の各々は、単一コアであってもよいし、キャッシュ等の特定のリソースを共有する２つ以上の単一コアを含むコアコンプレックスであってもよい。
【0011】
グラフィックスコア１２０は、頂点処理、フラグメント処理、シェーディング、テクスチャブレンディング等のグラフィックス動作を高度に統合された並列形式で実行可能な高性能のグラフィックスプロセッシングユニット（ＧＰＵ）である。グラフィックスコア１２０は、ＳＭＮ１４５と、データファブリック１５０と、に双方向接続されており、メモリアクセス要求をデータファブリック１５０に提供することができる。これに関連して、ＡＰＵ１００は、ＣＰＵコアコンプレックス１１０及びグラフィックスコア１２０が同じメモリ空間を共有するユニファイドメモリアーキテクチャ、又は、ＣＰＵコアコンプレックス１１０及びグラフィックスコア１２０がメモリ空間の一部を共有するメモリアーキテクチャの何れかをサポートすることができ、グラフィックスコア１２０は、ＣＰＵコアコンプレックス１１０がアクセスできないプライベートグラフィックスメモリも使用する。
【0012】
ディスプレイエンジン１３０は、モニタに表示するために、グラフィックスコア１２０によって生成されたオブジェクトをレンダリングし、ラスタライズする。グラフィックスコア１２０及びディスプレイエンジン１３０は、メモリ内の適切なアドレスへの均一な変換のために共通メモリ管理ハブ１４０に双方向接続されており、メモリ管理ハブ１４０は、このようなメモリアクセスを生成し、メモリシステムから返信された読み出しデータを受信するために、データファブリック１５０に双方向接続されている。
【0013】
データファブリック１５０は、任意のメモリアクセスエージェントとメモリコントローラ１９０との間でメモリアクセス要求及びメモリ応答をルーティングするためのクロスバースイッチを含む。また、データファブリック１５０は、システム構成に基づいてメモリアクセスの宛先を決定するために基本入出力システム（ＢＩＯＳ）によって定義されるシステムメモリマップと、各仮想接続のためのバッファと、を含む。
【0014】
周辺機器コントローラ１６０は、ＵＳＢコントローラ１６２と、シリアルアドバンスドテクノロジアタッチメント（ＳＡＴＡ）インタフェースコントローラ１６４と、を含み、これらの各々は、システムハブ１６６と、ＳＭＮ１４５と、に双方向接続されている。これらの２つのコントローラは、ＡＰＵ１００において使用され得る周辺機器コントローラの例示に過ぎない。
【0015】
周辺機器バスコントローラ１７０は、システムコントローラハブ１７２と、周辺機器コントローラハブ１７４と、を含み、これらの各々は、入力／出力（Ｉ／Ｏ）ハブ１７６と、ＳＭＮ１４５と、に双方向接続されている。システムコントローラハブ１７２は、適切な通信リンクを介してフラッシュメモリ２２０に接続する。また、Ｉ／Ｏハブ１７６は、システムハブ１６６と、データファブリック１５０と、に双方向接続されている。したがって、例えば、ＣＰＵコアは、データファブリック１５０がＩ／Ｏハブ１７６を介してルーティングするアクセスを介して、ＵＳＢコントローラ１６２、ＳＡＴＡインタフェースコントローラ１６４、システムコントローラハブ１７２又は周辺機器コントローラハブ１７４のレジスタをプログラミングすることができる。
【0016】
ＳＭＵ１８０は、ＡＰＵ１００上のリソースの動作を制御し、これらの間の通信を同期させるローカルコントローラである。ＳＭＵ１８０は、ＡＰＵ１００上の様々なプロセッサの起動シーケンスを管理し、リセット、イネーブル及び他の信号を介して複数のオフチップデバイスを制御する。また、ＳＭＵ１８０は、様々なプロセッサ及び他の機能ブロックの電源を管理する。
【0017】
プラットフォームセキュリティプロセッサ（ＰＳＰ）２１０は、ＡＰＵ１００に搭載されたファームウェアブートプロセスを制御するローカルセキュリティコントローラである。ＰＳＰ２１０は、以下にさらに説明するように、特定のソフトウェア検証及びファームウェアアンチロールバック（ＦＡＲ）機能を行う。
【0018】
ＳｏＣの実施形態を示しているが、これは限定的なものではなく、他のコンピューティングプラットフォームも、本明細書に記載のＦＡＲ技術から恩恵を受け得る。
【0019】
図２は、いくつかの実施形態による、ＰＳＰ２１０のより詳細なブロック図である。ＰＳＰ２１０は、マイクロコントローラコア２１２と、マイクロコントローラコア２１２に接続されたスタティックＲＡＭ（ＳＲＡＭ）２１６等のＲＡＭと、マイクロコントローラコア２１２に接続されたブートＲＯＭ２１８と、マイクロコントローラコア２１２に接続された複数のライトワンスメモリビット２１４と、を備える。
【0020】
一般的に、ＰＳＰ２１０は、ＡＰＵ１００のセキュリティプロセッサとして動作する。ＰＳＰ２１０は、セキュアな検証を行うために使用される暗号論理回路や、ＳＭＮ１４５及びデータファブリック１５０と通信するためのインタフェース論理回路等の追加の機能ブロック（明確にするために図示省略）を含むことができる。動作中、ＰＳＰ２１０は、本明細書に記載のＦＡＲ機能を実施することを含むＡＰＵ１００のセキュアブートを行い、ＣＰＵコアコンプレックス１１０及びＡＰＵ１００の他の周辺機器コントローラによって要求される他のセキュリティ関連機能を行う。
【0021】
ブートＲＯＭ２１８は、好ましくは、改ざん防止機能を備えたセキュアブートＲＯＭであり、ＰＳＰ２１０を初期化するための実行可能コード及び構成データを保持する。
【0022】
ライトワンスメモリビット２１４は、好ましくは、後述する最小セキュリティパッチレベル（ＳＰＬ）を記憶するためのアレイとして構成された３２ビットアレイ等の複数のライトワンスビットを含む。ライトワンスメモリビット２１４は、他の値を追跡するために使用されるシングルビット又は他のビットアレイを含んでもよい。ビットは、好ましくは、ＰＳＰ２１０と共にオンチップに配置されるヒューズとして実装されるが、任意の適切なライトワンス技術が使用されてもよい。この特定のセキュリティプロセッサの実施形態が一例として与えられているが、適切なセキュアメモリ及びライトワンスメモリビットと組み合わせた場合に本明細書に記載の機能を実施する他のタイプのセキュリティプロセッサが採用されてもよい。
【0023】
図３は、いくつかの実施形態による、ファームウェアを検証及びロードするプロセス３００を示すフロー図である。プロセス３００は、一般的に、ＰＳＰ２１０等のセキュリティプロセッサで実行され、ハードウェアルートオブトラスト（hardware root of trust）として機能するライトワンスセキュリティパッチレベル（ＳＰＬ）を定義するＦＡＲ機能を実施する。最小ＳＰＬは、ファームウェアが以前のバージョンにロールバックされるのを抑制するように、重大なアップデートがファームウェアに行われたときに更新される最小バージョン番号である。プロセス３００は、ブロック３０２で開始し、セキュリティプロセッサに統合されたセキュアＲＯＭ等のブートＲＯＭからセキュリティプロセッサをブートする。この実施形態では、セキュリティプロセッサがブートされるブートＲＯＭコードは、ブロック３２０までプロセス３００を制御する命令を含み、ブロック３２０で、ブートローダコードは、プロセス３００を実行及び制御することができる。
【0024】
ブロック３０４で、プロセス３００は、ＳＥＣＵＲＥ状態が有効にされるかどうかをチェックする。このチェックは、１つ以上のライトワンスビット（通常、工場出荷時の設定時に書き込まれるか焼き込まれる）をチェックして、ＳＥＣＵＲＥ状態が望ましいことと、ＦＡＲ機能が有効にされることと、を判別することを含むことができる。ＳＥＣＵＲＥ状態が有効でない場合、プロセス３００は、ブロック３０６に進み、ＦＡＲ機能を使用せずに、ホストプラットフォームの非セキュアブートを行う。
【0025】
ブロック３０４でＳＥＣＵＲＥ状態が有効にされる場合、プロセス３００は、ブロック３０８に進み、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得する。読み取りに失敗した場合、又は、無効な値を返した場合、プロセス３００は、ブロック３１０に進み、ブートプロセスを停止する。このような停止は、停止の理由を記憶する不揮発性メモリに対して失敗のレコードを記憶することを含む。
【0026】
ブロック３０８でライトワンスメモリビットの読み取りに成功した後、ブロック３１２で、ファームウェアセキュリティテーブル（ＦＳＴ）がロードされ、検証される。通常、ＦＳＴは、ホストＳｏＣに搭載されてもよい不揮発性メモリ、又は、図１のフラッシュメモリ２２０等の別個のチップであってもよい不揮発性メモリから、セキュリティプロセッサに搭載されたＳＲＡＭ２１６にロードされる。ＦＳＴは、ファームウェアコードモジュールの複数のファームウェア識別子と、各ファームウェア識別子に関連付けられた複数のチェックＳＰＬ値と、を含む。これについては、図５及び図６を参照してさらに説明する。ＦＳＴ検証は、記憶された署名又は他の適切な値に対してＦＳＴの暗号チェックを行って、ＦＳＴが変更されていないことを確認することを含む。ブロック３１２で検証に失敗すると、ブロック３１３でリカバリ手順が開始される。この手順では、ブートを停止してもよいし、最小ＳＰＬチェックを満たす以前のＦＳＴバージョンが使用可能な場合にはそのバージョンでリカバリを試みてもよい。セーフモードへの非セキュアブート、又は、他の適切なリカバリ手順を使用してもよい。
【0027】
ブロック３１２で、ＦＳＴのロード及び検証に成功すると、ブロック３１４で、ＦＳＴに記憶されたテーブルＳＰＬ値を読み取り、テーブルＳＰＬがブロック３０８で取得された最小ＳＰＬ以上であることを検証する。テーブルＳＰＬがこのチェックに合格しない場合、プロセス３００は、ブロック３１３のリカバリ手順に進む。
【0028】
テーブルＳＰＬがブロック３１４のチェックに合格すると、ブロック３１６で、ブートローダがロードされ、検証される。ブートローダは、フラッシュメモリ２２０（図１）等のオフチップの不揮発性メモリからロードされることが好ましい。検証は、ブートローダ実行可能コードの署名と記憶された値との比較、又は、公開鍵を用いた署名のチェック等の適切な周知の暗号検証を含む。ブートローダがロード及び検証に失敗した場合、プロセス３００は、ブロック３１３のリカバリ手順に進む。
【0029】
ブロック３１６で、ブートローダがロード及び検証に成功すると、ブロック３１８で、ブートローダＳＰＬが、ＦＳＴからのブートローダチェックＳＰＬと比較される。この比較は、ブートローダＳＰＬ値が、ＦＳＴに記憶されたブートローダチェックＳＰＬ値以上であるかどうかをチェックすることを含む。ブートローダＦＳＴは、図６を参照して説明するブートローダ等のファームウェアヘッダから、ブートローダと共に取得されることが好ましい。ブロック３１８でチェックに失敗すると、プロセス３００は、ブロック３１３のリカバリ手順に進む。
【0030】
ブロック３１８でチェックに合格すると、ブロック３２０で、ブートローダがセキュリティプロセッサにロードされ、実行される。この時点で、ブートローダは、プロセス３００を制御して、ホストプラットフォームをブートするのに必要な残りのファームウェアモジュールを検証する。プロセス３００は、ブロック３２２に進み、ブートローダは、所望のファームウェアモジュールが全てロードされるまで、ホストシステム上の様々なコントローラのファームウェアモジュールのロード、確認（validate）及び検証（verify）の反復を開始する。ロード及び検証は上述したものと同様に進み、署名又は他の暗号チェックが各ファームウェアモジュールに関して計算され、記憶された値と比較される。ファームウェアモジュールがロード及び検証に失敗した場合、プロセス３００は、ブロック３１３のリカバリ手順に進む。
【0031】
ブロック３２２で、ファームウェアモジュールが検証に合格すると、ブロック３２４で、悪意のあるロールバックアクティビティを抑制するためのファームウェアモジュールの検証を進める。検証は、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ＦＳＴにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が各チェックＳＰＬ値以上であるかどうかをチェックすることを含む。ファームウェアＳＰＬ値は、ファームウェアモジュールと共にファームウェアヘッダに記憶されるのが好ましい。
【0032】
ブロック３２４で検証に合格すると、ブロック３２６で、ファームウェアは、ホストプラットフォーム上の対象のコントローラにロードされる。ブロック３２６は、ファームウェアをロード及び実行するために、セキュリティプロセッサから対象のコントローラへのコマンドを含んでもよい。ブロック３２４で検証に失敗すると、プロセス３００は、ブロック３１３のリカバリ手順に進む。
【0033】
ブロック３２６で各ファームウェアモジュールがロードされた後、プロセス３００は、ブロック３２２に進み、全てのモジュールがロードされるまで、次のファームウェアモジュールをロード及び検証する。
【0034】
本実施形態では、１つのＦＳＴが使用されているが、他の実施形態では、複数のＦＳＴを使用してもよく、各ＦＳＴは、本明細書に記載のＦＳＴと同様に、ライトワンスメモリＳＰＬ値又はＦＳＴのエントリに対してチェックされるＳＰＬ値を有する。例えば、ブートローダは、セキュアオペレーティングシステムのためのファームウェアモジュールのロード及び検証を提供してもよい。このために補助的なＦＳＴを使用してもよく、これは、セキュリティプロセッサ上で動作するブートローダによって検証され、次に、ＣＰＵコアコンプレックス１１０（図１）等の別のプロセッサの制御下にある追加のファームウェアモジュールを検証するために、セキュアオペレーティングシステムに利用可能にされる。このような場合、セキュリティプロセッサは、ファームウェアモジュールをロードするための、又は、ファームウェアモジュールをロードして検証するためのセキュアオペレーティングシステムからの要求を満たしてもよい。
【0035】
プロセス３００は、ファームウェアモジュールを検証することを含むが、他のタイプのモジュールをＦＳＴに対して検証して、アンチロールバック機能を提供してもよい。例えば、セキュアオペレーティングシステムモジュール又はライブラリは、上述したファームウェアモジュールと同様に検証及びロードされてもよい。
【0036】
プロセス３００は、この実施形態では、セキュアブートＲＯＭからの実行可能コードの制御の下で開始し、制御をブートローダに渡すが、他のバージョンは、異なる方法でセキュリティプロセッサを動作させてもよい。いくつかの実施形態では、セキュアブートＲＯＭは、ブートローダをロードすることなく、全てのファームウェアモジュールの検証を行ってもよい。図４のプロセス等の他のバージョンでは、ブートローダは、ライトワンスメモリビットを読み取り、ＦＳＴを検証するプロセスを制御してもよい。
【0037】
理解されるように、ファームウェアアップデートを検証するためのＦＳＴの本明細書に記載の使用は、ライトワンスメモリ内でファームウェアバージョンを直接追跡する技術よりも、必要とするライトワンスメモリビットが少ないという利点がある。最小ＳＰＬに対するＦＳＴの検証は、ライトワンスメモリの直接使用と同様のセキュリティレベルを提供するが、回路面積の使用が少ない。
【0038】
図４は、いくつかの実施形態による、ファームウェア及びソフトウェアを検証及びロードする別のプロセス４００のフロー図である。プロセス４００は、プロセス３００と同様の多くの動作を有するが、ブートＲＯＭコードにテーブルＳＰＬの初期の検証を制御させるのではなく、ブートローダを実行するセキュリティプロセッサによって行われる。この技術は、上記のアンチロールバック機能を維持しながら、セキュリティプロセッサの設定性（configurability）とアップグレード性（upgradeability）を向上させる。
【0039】
プロセス４００は、ブロック４０２で開始し、セキュリティプロセッサが、オフチップ不揮発性メモリに記憶されたブートローダを実行する。ブロック４０４，４０６は、ブートＲＯＭコードの代わりにブートローダの制御下にあることを除いて、ブロック３０４，３０６と同様に進行する。ブロック４０４で、プロセス４００は、ＳＥＣＵＲＥ状態が有効にされるかどうかをチェックする。ＳＥＣＵＲＥ状態が有効にされない場合、プロセス３００は、ブロック３０６に進み、ＦＡＲ機能を使用せずに、ホストプラットフォームの非セキュアブートを行う。
【0040】
ブロック４０４で、ＳＥＣＵＲＥ状態が有効にされる場合、プロセス４００は、ブロック４０８に進み、ブートローダの制御下で、セキュリティプロセッサは、ライトワンスメモリビットのセットを読み取って、最小セキュリティパッチレベル（ＳＰＬ）を取得する。読み取りに失敗した場合又は無効な値を返した場合、プロセス４００は、ブロック４１０に進み、ブートプロセスを停止する。
【0041】
ブロック４０８でライトワンスメモリビットの読み取りに成功した後、ブロック４１２で、ファームウェアセキュリティテーブル（ＦＳＴ）がロードされ、検証される。ＦＳＴは、図３に関して説明したＦＳＴと同様である。ブロック４１２で検証に失敗すると、ブロック４１３のリカバリ手順に移行する。この手順では、ブートを停止してもよいし、ブロック４１４で最小ＳＰＬチェックを満たす以前のＦＳＴバージョンが利用可能である場合、そのバージョンでリカバリを試みてもよい。セーフモードへの非セキュアブート、又は、他の適切なリカバリ手順を使用してもよい。
【0042】
ブロック４１２で、ＦＳＴのロード及び検証に成功した場合、ブロック４１４で、セキュリティプロセッサは、ブートローダの制御下で、ＦＳＴに記憶されたテーブルＳＰＬ値を読み取り、アップデートが必要かどうかを確認するためにテーブルＳＰＬをチェックするシーケンスを行う。ブロック４１４は、テーブルＳＰＬがブロック４０８で取得された最小ＳＰＬよりも小さいかどうかをチェックする。小さい場合、プロセス４００は、ブロック４１３のリカバリ手順に進む。
【0043】
ブロック４１４で、テーブルＳＰＬが最小ＳＰＬよりも小さくない場合であっても、依然として、最小ＳＰＬへのアップデートを必要とする場合がある。ブロック４１５では、テーブルＳＰＬが最小ＳＰＬと等しいかどうかをチェックする。等しくない場合、プロセス４００は、ブロック４１６に進み、ライトワンスメモリビットで最小ＳＰＬをアップデートする必要かあるかどうかをチェックする。このチェックは、最小ＳＰＬへのアップデートを必要とするファームウェアアップデートが行われたことを検出する。チェックは、アップデートが行われた場合に、セキュアアップデートコードによって構成することができる１つ以上の設定を使用して実施されてもよい。ヒューズ等のライトワンスメモリビットは、ＳＰＬアップデートフラグとして機能してもよく、そのビットが、ＳＰＬアップデートが必要であることを示すように予め設定されているかどうかを確認するためにセキュアプロセッサによってチェックされてもよい。このようなビットは、通常、複数のアップデートを可能にするセキュリティプロセッサに搭載されている多くのビットの１つである。設定されている場合、ブートローダは、最小ＳＰＬ値をアップデートする必要がある。ライトワンスビットに加えて、又は、その代わりに、アップデートを検出するために別のチェックが行われてもよい。例えば、ＳＰＬアップデートフラグをライトワンスメモリビットに設定する必要があることを示すＢＩＯＳフラグが設定されてもよい。このようなシナリオは、ＢＩＯＳがセキュアであると信頼されているアーキテクチャでのみ使用すべきである。ＢＩＯＳフラグがＳＰＬアップデートフラグを必要とする場合、プロセス４００は、他のアクションを行う前に、ＳＰＬアップデートフラグを設定する。ブロック４１６で、最小ＳＰＬアップデートが必要とされない場合、プロセス４００は、ブロック４１８に進む。
【0044】
ブロック４１６で、最小ＳＰＬアップデートを必要とするアップデートが検出された場合、ブロック４１７は、新しい値をライトワンスメモリビットに書き込むことによって、最小ＳＰＬをテーブルＳＰＬに設定する。最小ＳＰＬへのアップデートは、リブートを必要としてもよいし、ブロック４１８に進んでもよい。
【0045】
ブロック４１８は、ブートローダＳＰＬがＦＳＴのブートローダチェックＳＰＬ以上であるかどうかをチェックすることによって、ブートローダを検証する。ブートローダＳＰＬがこのチェックに合格しない場合、プロセス４００は、ブロック４１３のリカバリ手順に進む。
【0046】
ブロック４１８でブートローダＳＰＬがチェックに合格すると、プロセス４００は、ブロック４２２に進み、ファームウェアモジュールのロード、確認及び検証を開始する。ブロック４２２で、ブートローダは、所望のファームウェアモジュールが全てロードされるまで、ホストシステム上の様々なコントローラのファームウェアモジュールのロード、確認及び検証の反復を開始する。ロード及び検証は上述したものと同様に進み、署名又は他の暗号チェックがファームウェアモジュール毎に計算され、記憶された値と比較される。ファームウェアモジュールがロード及び検証に成功しない場合、プロセス４００は、ブロック４１３のリカバリ手順に進む。
【0047】
ブロック４２２でファームウェアモジュールが検証に合格すると、ブロック４２４で、悪意のあるロールバックアクティビティを抑制するためのファームウェアモジュールの検証を進める。検証は、ファームウェアコードモジュール毎に、（ａ）各ファームウェアモジュールにアクセスして、各ファームウェアＳＰＬ値を取得すること、（ｂ）ＦＳＴにアクセスして、各チェックＳＰＬ値を取得すること、及び、（ｃ）各ファームウェアＳＰＬ値が各チェックＳＰＬ値以上であるかどうかをチェックすることを含む。ファームウェアＳＰＬ値は、ファームウェアモジュールと共にファームウェアヘッダに記憶されるのが好ましい。
【0048】
ブロック４２４で検証に合格すると、ブロック４２６で、ファームウェアは、ホストプラットフォーム上の対象のコントローラにロードされる。ブロック４２６は、ファームウェアをロード及び実行するためのセキュリティプロセッサから対象のコントローラへのコマンドを含む。ブロック４２４で検証に失敗すると、プロセス４００は、ブロック４１３のリカバリ手順に進む。ブロック４２６で各ファームウェアモジュールがロードされた後、プロセス４００は、ブロック４２２に進み、全てのモジュールがロードされるまで、次のファームウェアモジュールをロードして検証する。
【0049】
ブロック４１５，４１６，４１７で最小ＳＰＬ値をアップデートする手順は、図３のプロセス３００に統合されてもよく、ブートＲＯＭ又はブートローダの制御下で行われてもよいことに留意されたい。
【0050】
図５は、いくつかの実施形態による、ファームウェアセキュリティテーブル（ＦＳＴ）５００を示す図である。上述したように、ＦＳＴ５００は、好ましくは、フラッシュメモリ等の不揮発性メモリに記憶され、その後、ＰＳＰ２１０によってＳＲＡＭ２１６（図２）にロードされ、ファームウェアの検証に使用される。ＦＳＴ５００は、ファームウェアイメージＩＤ列によって示されるように、ファームウェアコードモジュールのファームウェア識別子のセットを含む。ＦＳＴ５００は、各々のファームウェア識別子に関連付けられた複数のチェックＳＰＬ値を含む。
【0051】
図６は、いくつかの実施形態による、ファームウェアモジュール６００を示す図である。ファームウェアモジュール６００は、本明細書のＦＡＲ技術と共に使用される実行可能なファームウェアプログラムコードとファームウェアヘッダとを含む。ファームウェアヘッダは、ファイルヘッダとして存在するか、不揮発性メモリに記憶されたファームウェア実行可能コードに関連付けられる。ファームウェアヘッダは、ＦＳＴの関連ＩＤと一致するファームウェアイメージＩＤを含む。ヘッダバージョンは、ヘッダのバージョンを識別し、ヘッダフォーマットの解釈に使用されてもよい。ＦＳＴに記憶された関連するＳＰＬ値に対してチェックする上記の検証に使用されるファームウェアＳＰＬが含まれる。署名等の他のデータ項目もファームウェアヘッダに含まれてよい。さらに、同様の構造が、セキュリティプロセッサによって検証される他のファームウェア又はソフトウェア（例えば、セキュアオペレーティングシステム（ＯＳ）実行可能コード又は他のソフトウェアコード等）と共に使用されてもよい。
【0052】
図１のＡＰＵ１００若しくはその一部、又は、本明細書の技術を使用するデータ処理プラットフォームの他の実施形態は、プログラムによって読み取ることができ、集積回路を製造するために直接的又は間接的に使用することができるデータベース又は他のデータ構造の形態のコンピュータアクセス可能なデータ構造によって記述又は表現されてもよい。例えば、このデータ構造は、Ｖｅｒｉｌｏｇ又はＶＨＤＬ等の高レベル設計言語（ＨＤＬ）におけるハードウェア機能の動作レベル記述又はレジスタ転送レベル（ＲＴＬ）記述であってもよい。記述は、合成ツールによって読み取られてもよく、合成ツールは、記述を合成して、合成ライブラリからゲートのリストを含むネットリストを生成してもよい。ネットリストは、集積回路を含むハードウェアの機能を表すゲートのセットを含む。次に、ネットリストは、マスクに適用される幾何学形状を記述するデータ集合を生成するために配置され、ルーティングされてもよい。次に、マスクは、集積回路を製造するために様々な半導体製造工程において使用されてもよい。或いは、コンピュータアクセス可能な記憶媒体上のデータベースは、必要に応じて、ネットリスト（合成ライブラリの有無にかかわらず）若しくはデータセット、又は、グラフィックデータシステム（ＧＤＳ）ＩＩデータであってもよい。
【0053】
特定の実施形態を説明したが、これらの実施形態に対する様々な修正が当業者に明らかであろう。例えば、ライトワンスメモリビットに記憶された最小ＳＰＬをそれぞれ有する複数のＦＳＴが使用されてもよい。他のタイプのソフトウェアがＦＳＴを使用して検証されてもよい。ライトワンスメモリビット、ブートＲＯＭ、及び、不揮発性メモリの特定の位置は、セキュリティの制約内で変更されてもよい。さらに、セキュリティプロセッサは、ホストシステムの他のプロセッサ又はコントローラに対するサービスとして、ＦＳＴに記憶されたＳＰＬ値に対してファームウェアモジュール又はソフトウェアモジュールの検証を行ってもよい。本明細書に記載のセキュアＦＡＲ機能を変更することなく、ＦＳＴに記憶されたデータ値に対して様々な暗号化スキームが使用されてもよい。
【0054】
したがって、添付の特許請求の範囲は、開示の範囲内に収まる開示された実施形態の全ての修正をカバーすることを意図している。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】