NI LabVIEWは、データ収集、計測器制御、およびテスト自動化に広く使用されているグラフィカルプログラミングプラットフォームです。メモリの安全性に関する脆弱性は、従来のソフトウェア環境の多くで問題となっていますが、LabVIEWはそのアーキテクチャと設計原則によって際立っています。 このホワイトペーパーでは、LabVIEWをメモリセーフ言語(MSL)にするメカニズムと機能、これらの属性と従来のプログラミング言語の違い、および堅牢で信頼性が高く安全なアプリケーションを求める開発者への影響について説明します。
メモリの安全性は、ソフトウェアのセキュリティと信頼性にとって重要です。バッファオーバーフロー、解放後使用エラー、およびダングリングポインタなどの従来のメモリ安全性の問題は、CやC++などの言語のソフトウェアの欠陥やセキュリティの脆弱性の大部分の原因となっています。1 それに対し、LabVIEWは、高レベルのデータフロー駆動型グラフィカル環境によって、これらのリスクの多くを抽象化します。
メモリ安全性とは、プログラムが明確に定義された予測可能な方法でメモリにアクセスすることを保証することです。この機能は、破損、リーク、意図しない境界外へのデータの書き込みを防ぐのに役立ちます。これらのメモリの問題により、クラッシュや未定義の動作が発生する可能性があります。さらに悪いことに、脅威アクターはメモリの問題を操作して任意のコードを実行し、メモリバグを重大なセキュリティの脆弱性に変えます。メモリの安全性に関する懸念事項には、以下のタイプの問題が含まれます。
ダイレクトメモリアクセスを提供する言語 (たとえばポインタを使用) は、特にこれらの問題の影響を受けやすくなります。一方、メモリセーフな言語では、開発者による直接メモリ管理を制限または完全に抽象化します。
LabVIEWは、従来のテキストベースの言語とは根本的に異なります。グラフィカルプログラミングのパラダイムは、ノード間のデータフロー(VI)によってコードの実行が決定されるデータフローの原則に基づいています。
LabVIEW固有のアーキテクチャには、メモリの安全性を促進する次のような特徴があります。
LabVIEWでは、プログラムは機能ブロックをデータを扱うワイヤで接続して構築されます。各ブロックは、すべての必要な入力が使用可能な場合にのみ実行され、データが生成される前にデータ位置にアクセスできないため、メモリ競合状態を回避できます。
図1.LabVIEWコード例
このモデルは、命令型言語での不適切な操作シーケンスによって発生する多くのプログラミングエラーを回避します。
LabVIEWランタイムエンジンは、すべてのメモリの割り当てと割り当て解除を行います。開発者はメモリを手動で要求または解放する必要がないため、リークや解放後使用エラーのリスクを排除できます。配列またはクラスタ (構造体のようなデータ) が拡大または縮小すると、LabVIEWは関連するメモリを透過的に管理します。たとえば、開発者が配列を作成するループを作成した場合、LabVIEWは自動的に配列のサイズを変更し、関連するメモリ領域を管理します。配列変数がスコープ外になると、LabVIEWのガベージコレクタはメモリを再利用します。
LabVIEW開発環境は、VIのコンパイルおよび実行時に厳密なタイプチェックを実行します。互換性のないデータタイプ同士を配線しようとする試みは編集時に検出され、ランタイムエラーを防ぎます。さらに、配列および文字列操作には、バッファオーバーフローを防止するための境界チェックが含まれます。
最も効果的な対策の1つは、低レベルメモリ制御を行わないことです。LabVIEWには、ユーザが任意ポインタ演算を実行したり、メモリに直接アクセスするためのメカニズムはありません。 この設計は、スタックまたはヒープオーバーフローなど、Cまたはアセンブリで一般的な脆弱性が、ネイティブLabVIEWコードでは発生しないことを意味します。
LabVIEWのメモリ安全性を理解するには、C、C++、Java、Pythonなどの言語と比較することが有益です。
まとめると、LabVIEWの設計は、バッファオーバーフローなどのメモリ関連の脆弱性のカテゴリ全体を排除し、安全なアプリケーション開発を簡素化することで、PythonやJavaと同様の保護機能を備えたCやC++などの従来の言語よりも大きな利点を提供します。
LabVIEWのメモリの安全性は、開発者、組織、およびエンドユーザにとって明白な利点があります。
従来のバッファオーバーフローは、データが固定長バッファの境界を超えると発生し、隣接するメモリが上書きされ、任意のコードが実行される可能性があります。LabVIEWでは、配列および文字列操作は常に境界チェックされます。配列または文字列の末尾を超えて書き込もうとすると、サイレントメモリ破損ではなくランタイムエラーが発生します。
他のメモリセーフ環境と同様に、LabVIEWの境界を理解することが重要です。
外部コードを呼び出す際の安全性を最大限に高めるには、以下のベストプラクティスに従ってください。
LabVIEWの設計は、グラフィカルなデータフローパラダイム、強力なタイプチェック、自動メモリ管理、および直接ポインタ操作のない設計に基づいており、メモリ安全性の高い環境を提供します。開発者は、メモリ関連のバグのリスクを軽減し、生産性を向上させ、要求の厳しいセーフティクリティカルな業界向けのアプリケーションを確実に構築できるメリットがあります。
エラーの影響をまったく受けない環境はありませんが(特に安全でない外部コンポーネントと対話する場合)、LabVIEWは従来のテキストベースの言語に比べてメモリの安全性を大幅に向上させます。計測、自動化、制御アプリケーションに信頼性とセキュリティを求める組織にとって、LabVIEWはメモリセーフな開発に最適な製品です。
| 特徴 | C/C++ | Python/Java | LabVIEW |
|---|---|---|---|
| メモリアクセス | ダイレクトメモリアクセス | ダイレクトメモリアクセスなし | ダイレクトメモリアクセスなし |
| メモリ管理 | 手動メモリ管理(エラーが発生しやすい) | 自動メモリ管理 | 自動メモリ管理 |
| エラーの可能性 | メモリ安全エラー (例: バッファオーバーフロー) のリスクが大きい | 厳密な入力とメモリ管理により、リスクを大幅に軽減 | 厳密な入力とメモリ管理により、リスクを大幅に軽減 |
| ポインタ | ポインタの多用、複雑さとリスクの増大 | ポインタの直接使用不可 | ポインタの直接使用不可 |
| セキュリティ | メモリを手動で処理し、バッファオーバーフローの影響を受けやすいため、攻撃対象領域が大きい | バッファオーバーフローやポインタエクスプロイトの影響を受けない最小の攻撃対象領域 | バッファオーバーフローやポインタエクスプロイトの影響を受けない最小の攻撃対象領域 |
1 「メモリセーフ言語:『Reducing Vulnerabilities in Modern Software Development』、サイバーセキュリティおよびインフラストラクチャ庁、2025年6月、https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development。
JavaはOracleおよびその関連会社の登録商標です。その他の名前はそれぞれの所有者の商標です。