4

組み込みシステムで作業する場合、2 つのケースがあります。組み込みシステムには、12 K フラッシュを搭載した ARM Cortex M0 マイクロコントローラーなどの限られたリソースがあります。

ケース 1 : ブートローダーとファームウェアで共通の機能/モジュールの使用法: ブートローダーとファームウェアは、コードの重複を防ぐために同じモジュールと機能を使用する必要がある場合があります。そうしないと、同じコードがファームウェアとブートローダーの両方に 2 回含まれます。これを防ぐには、関数アドレスを指定し、アドレスで関数を呼び出すことでこの関数を呼び出します。これが解決策の 1 つです。

一般的な機能の使用法を提供するスマートな方法はありますか?

ケース 2 : ファームウェアをアップグレードする必要がある場合があります。ブートローダーの役割の 1 つは、ファームウェアのアップグレードです。古いものを上書きすることで、ファームウェアを簡単にアップグレードできます。

これまで見てきたように、2 つのケースは別々に実装できます。しかし、それらをマージすると、いくつかの問題が発生します。

質問 : ブートローダーは一般に静的オブジェクトですが、ファームウェアは変更できます。したがって、一般的な機能は通常、ブートローダーに配置されます。しかし、共通のモジュール/関数を更新する必要がある場合、どうすればよいでしょうか?

ブートローダー、ファームウェア構造化組み込みシステムの一般的またはスマートなアプローチは何ですか? さらに、限られたリソースのために。

共通のモジュール/機能を分離するには、1 つまたは複数の追加領域でこの問題を解決できますか。ファームウェア、ブートローダ、ライブラリ(新しい領域)?

一般論を学びたい。高度なファームウェア管理に関する論文、書籍、ソースはありますか?

ありがとう

4

3 に答える 3

2

あなたの質問は問題を正しく述べています-あなたはケーキを持って食べることはできません。1.
メモリ フットプリントを小さくし、ブートローダーにファームウェア アップグレード ロジックを含めない (つまり、ブートローダーはアプリケーション イメージの CRC などを検証するだけで、それ以上複雑なことはしない)。ここでは、機能を共有してスペースを節約できます。または
2. ブートローダにはファームウェア アップグレード機能があります。ここでは、共有関数をアプリとブートローダーの両方にコンパイルする必要があります。共有関数は小さくする必要があります-おそらく大きなオーバーヘッドではありませんが、これに必要なスペースが必要です-それがない場合は、より多くのメモリを用意する必要があります。
機能を共有し、ブートローダーからファームウェア アップグレードを確実に行う方法はありません。

于 2015-05-22T07:33:38.353 に答える
2

ファームウェア アップデート プロセスにおけるセキュリティに関する現在の議論に照らして、明確にするために次のことを追加したいと思います。

ブートローダ部分は、実際には変更したくない部分です。これは、可能な限り静的にする必要があります。ブートローダーが壊れていると、現場での更新がほぼ不可能になるか、少なくとも安全ではなくなります。

そうは言っても、別のアプローチを使用することをお勧めします。デバイスのメンテナンス モードを作成できます。このモードは JTAG インターフェイスを開き、メモリへの直接アクセスを可能にします。サービス技術者がアップデートを適用するよりも。

これで、メンテナンス モードのアクティブ化を「保護する」だけで済みます。次の方法でうまくいく可能性があります: UART インターフェイスを使用して、アクティベーションを通信します。

  1. 保守システムは独自の ID を送信し、UART 経由で保守モードを要求します
  2. 保守システムの ID、乱数、および一意のシステム ID が保守システムに送り返されます。
  3. 保守システムは、この ID シーケンスを認証サーバーに送信します。
  4. 一意のシステム ID と保守システム ID が正しい場合、サーバーは受信した情報の署名を作成し、それを保守システムに送り返します。
  5. これで、システムは UART 経由で署名を受け取ります
  6. システムは、本番中に保存された公開鍵を使用して、以前に送信された ID 文字列に対して署名を検証します
  7. 検証が成功すると、メンテナンス モードに入ります

セキュリティを追加するには、同様のスキームに従ってシステム ID のメンテナンスに力を入れる必要があります。ID は基本的に、MAC アドレスまたは別の一意のハードウェア ID とその署名に依存する必要があります。ID は、保守システムの生産プロセス中に安全な環境で作成する必要があります。一意のハードウェア ID は、外部から見えるものにする必要があります。これにより、サーバーは、受信した ID がサーバーと通信している保守システムと一致するかどうかを実際に検証できます。

このセットアップ全体により、ブートローダーなしで安全なファームウェア アップデートが提供されます。安全なファームウェア更新を行うには、RSA のような非対称暗号化に基づく認証システムが必要であるというのが一般的な理解です。とにかく検証コードが必要な場合は、上記により、更新を受け入れることができるブートローダーが単純な UART インターフェイスと交換され、プロセスのリソースが節約されます。

これはあなたが探していたものですか？

私の経験では、市販のブートローダは、フラッシュ アルゴリズムやその他の条件に応じて、4 ～ 8k のフラッシュ メモリを使用します。私はキャリアを通じて同じベンダーに固執してきたので、これはあなたの経験と異なる場合があります.

組み込みシステム用に最適化されたデジタル署名システムは、フラッシュ メモリで約 4.5k バイトを使用し (例については、https ://www.segger.com/emlib-emsecure.html を参照)、スタックよりも多くの RAM を使用しません。

ご覧のとおり、12k は、現場で安全に更新できるシステムを持つという点で、非常に低くなっています。ブートローダーを使用してシステムを更新する場合はなおさらです。

于 2015-08-11T14:10:16.583 に答える
2

ブートローダとメインライン ファームウェア アプリケーションの間でコードを共有する場合、ブートローダはアプリケーション スペースをフラッシュするときにこのコードを使用します。この状態を防ぐには、共通コードを更新する機能を犠牲にする必要があります。そうしないと、ブートローダーがクラッシュします。

わずか 12k のフラッシュで、ブートローダーとメインライン アプリケーションが収まると期待するのはかなり野心的です。アセンブリでブートローダーを書くことを検討するかもしれません (あえぎ!)。一部の Cortex M0 パーツ (NXP LPC11xx ファミリなど) には、いくつかの有用な機能を格納し、メモリの制約の一部を緩和するのに役立つ追加のブート ROM があります。

于 2013-08-01T02:55:51.747 に答える