CERT C: Rule CON32-C

複数のスレッドからビットフィールドにアクセス中のデータレースを回避する

説明

このチェッカーは、既定の Polyspace^® as You Code 解析では非アクティブにされます。Polyspace as You Code 解析で非アクティブにされるチェッカー (Polyspace Access)を参照してください。

ルール定義

複数のスレッドからビットフィールドにアクセス中のデータレースを回避します。¹

Polyspace 実装

ルールチェッカーは、"隣接するビットフィールドでのデータレース" をチェックします。

チェッカーの拡張

ルールチェッカーが問題を検出できるようにするには、スレッドの作成と共有変数の保護のために Polyspace が認識する同時実行プリミティブの 1 つをコードで使用する必要があります。あるいは、プロジェクト構成でタスク、割り込み、クリティカルセクション、およびその他のマルチタスクオプションを明示的に指定する必要があります。マルチタスキングを参照してください。

例

すべて展開する

隣接するビットフィールドでのデータレース

問題

隣接するビットフィールドでのデータレースは、以下の条件の両方に該当する場合に発生します。

複数のタスクが、同じ構造体の一部であるビットフィールドに対して非保護操作を実行した。
たとえば、次の型の変数で、あるタスクがフィールド errorFlag1 を操作し、別のタスクがフィールド errorFlag2 を操作した場合です。
```
struct errorFlags {
   unsigned int errorFlag1 : 1;
   unsigned int errorFlag2 : 1;
   //...
};
```
操作は相互にアトミックではないと仮定します。つまり、ある操作が完了してから次の操作が開始されるようにするための保護メカニズムが実装されていません。
非保護操作のうち少なくとも 1 は書き込み操作である。

この欠陥を検出するには、解析前にマルチタスキングオプションを指定します。[構成] ペインで [マルチタスキング] を選択してこれらのオプションを指定します。詳細は、Polyspace マルチタスキング解析の手動設定を参照してください。

リスク

同じ構造体の一部である隣接するビットフィールドは、同じメモリ位置にある 1 バイトに保存される可能性があります。ビットフィールドを含むすべての変数に対する読み取り操作または書き込み操作は、一度に 1 バイトまたは 1 ワードで発生します。1 つのバイト内の特定のビットのみを変更するには、次のようなステップが順番に発生します。

そのバイトが RAM に読み込まれます。
特定のビットだけが意図された値に変更され、残りのビットは変更されないようにマスクが作成されます。
RAM 内のバイトのコピーとマスク間でビット OR 演算が実行されます。
特定のビットが変更されたバイトが RAM からコピーされます。

2 つの異なるビットフィールドにアクセスする場合は、各ビットフィールドに対してこの 4 つのステップを実行する必要があります。アクセスが保護されていない場合は、1 つのビットフィールドに対する 4 つすべてのステップが完了しなくても、他のビットフィールドに対する 4 つのステップが開始される可能性があります。その結果、1 つのビットフィールドの変更によって、隣接するビットフィールドの変更が取り消される可能性があります。たとえば、前述の例では、errorFlag1 と errorFlag2 の変更を次の順序で行うことができます。

ステップ 1、2、および 5 は errorFlag1 の変更に関連しますが、ステップ 3、4、および 6 は errorFlag2 の変更に関連します。

変更されていない errorFlag1 と errorFlag2 の両方を含むバイトが errorFlag1 を変更する目的で RAM にコピーされます。
errorFlag1 だけを変更するマスクがこのコピーとビット単位 OR されます。
errorFlag2 を変更する目的で、変更されていない errorFlag1 と errorFlag2 の両方を含むバイトが 2 回 RAM にコピーされます。
errorFlag2 だけを変更するマスクがこの 2 つ目のコピーとビット単位 OR されます。
errorFlag1 が変更されたバージョンがコピーされます。このバージョンの errorFlag2 は変更されていません。
errorFlag2 が変更されたバージョンがコピーされます。このバージョンの errorFlag1 は変更されておらず、以前の変更が上書きされます。

修正方法

この欠陥を修正するには、クリティカルセクション、時間的排他、または別の手段を使用して同じ構造体の一部であるビットフィールドに対する操作を保護します。マルチタスキングコードでの共有変数の保護を参照してください。

再利用できる既存の保護を特定するには、結果に関連付けられている表とグラフを確認します。表では競合する呼び出しの各ペアが示されます。[アクセス保護] 列には、その呼び出しについての既存の保護が表示されます。競合につながる関数呼び出しの順序を確認するには、アイコンをクリックします。

例 - グローバル変数に対する複数のタスクからの保護されない操作


typedef struct
{
   unsigned int IOFlag :1;
   unsigned int InterruptFlag :1;
   unsigned int Register1Flag :1;
   unsigned int SignFlag :1;
   unsigned int SetupFlag :1;
   unsigned int Register2Flag :1;
   unsigned int ProcessorFlag :1;
   unsigned int GeneralFlag :1;
} InterruptConfigbits_t;

InterruptConfigbits_t InterruptConfigbitsProc12; //Noncompliant

void task1 (void) {
    InterruptConfigbitsProc12.IOFlag = 0;
}

void task2 (void) {
    InterruptConfigbitsProc12.SetupFlag = 0;
}

この例では、task1 と task2 が、同じ構造化変数 InterruptConfigbitsProc12 に属している別々のビットフィールドの IOFlag と SetupFlag にアクセスします。

マルチタスキング動作をエミュレートするには、次の表に記載されたオプションを指定します。

オプション仕様

オプション	仕様
マルチタスクを手動で構成
タスク	`task1` `task2`

マルチタスクを手動で構成

タスク

task1

task2

コマンドラインで、以下を使用します。

 polyspace-bug-finder 
   -entry-points task1,task2

修正 – クリティカルセクションを使用

1 つの修正方法として、1 つのクリティカルセクションでビットフィールドのアクセスをラップします。クリティカルセクションは、ロック関数およびロック解除関数に対する呼び出しの間に配置されます。この修正では、クリティカルセクションが関数の begin_critical_section と end_critical_section に対する呼び出しの間に配置されます。


typedef struct
{
   unsigned int IOFlag :1;
   unsigned int InterruptFlag :1;
   unsigned int Register1Flag :1;
   unsigned int SignFlag :1;
   unsigned int SetupFlag :1;
   unsigned int Register2Flag :1;
   unsigned int ProcessorFlag :1;
   unsigned int GeneralFlag :1;
} InterruptConfigbits_t;

InterruptConfigbits_t InterruptConfigbitsProc12;

void begin_critical_section(void);
void end_critical_section(void);

void task1 (void) {
    begin_critical_section();
    InterruptConfigbitsProc12.IOFlag = 0;
    end_critical_section();
}

void task2 (void) {
    begin_critical_section();
    InterruptConfigbitsProc12.SetupFlag = 0;
    end_critical_section();
}

この例では、マルチタスキング動作をエミュレートするために、次の表に記載されたオプションを指定します。

オプション	仕様
マルチタスクを手動で構成
タスク	`task1` `task2`
クリティカルセクション詳細	開始ルーチン	終了ルーチン
クリティカルセクション詳細	`begin_critical_section`	`end_critical_section`

コマンドラインで、以下を使用します。

 polyspace-bug-finder 
   -entry-points task1,task2
   -critical-section-begin begin_critical_section:cs1
   -critical-section-end end_critical_section:cs1

修正 – ビットフィールドを回避

メモリ制約がない場合は、ビットフィールドの代わりに、char データ型を使用します。構造体内の変数 char は、少なくとも 1 バイトを占有し、バイトサイズの操作におけるビット操作から発生するスレッド安全性問題を引き起こしません。データレースは、同じ構造体の一部である複数の変数 char に対する非保護操作から派生しません。

typedef struct
{
   unsigned char IOFlag;
   unsigned char InterruptFlag;
   unsigned char Register1Flag;
   unsigned char SignFlag;
   unsigned char SetupFlag;
   unsigned char Register2Flag;
   unsigned char ProcessorFlag;
   unsigned char GeneralFlag;
} InterruptConfigbits_t;

InterruptConfigbits_t InterruptConfigbitsProc12;

void task1 (void) {
    InterruptConfigbitsProc12.IOFlag = 0;
}

void task2 (void) {
    InterruptConfigbitsProc12.SetupFlag = 0;
}

チェッカーはこの修正にフラグを設定しませんが、C99 以前ではこの修正を使用しないでください。C11 以降でのみ、同じワードを使用して異なる変数 char にアクセスできないことが C 標準で義務付けられます。

修正 – サイズ 0 のビットフィールドを挿入

同時にアクセス可能な 2 つの隣接するビットフィールドの間に非ビットフィールドメンバーまたはサイズ 0 の無名のビットフィールドメンバーを入力できます。非ビットフィールドメンバーまたはサイズ 0 のビットフィールドメンバーは、後続のビットフィールドが新しいメモリ位置から始まるようにします。この修正例では、サイズ 0 のビットフィールドメンバーが、IOFlag と SetupFlag が異なるメモリ位置に保存されるようにします。

typedef struct
{
   unsigned int IOFlag :1;
   unsigned int InterruptFlag :1;
   unsigned int Register1Flag :1;
   unsigned int SignFlag :1;
   unsigned int : 0;
   unsigned int SetupFlag :1;
   unsigned int Register2Flag :1;
   unsigned int ProcessorFlag :1;
   unsigned int GeneralFlag :1;
} InterruptConfigbits_t;

InterruptConfigbits_t InterruptConfigbitsProc12;

void task1 (void) {
    InterruptConfigbitsProc12.IOFlag = 0;
}

void task2 (void) {
    InterruptConfigbitsProc12.SetupFlag = 0;
}

チェック情報

グループ: Rule 14.同時実行 (CON)

バージョン履歴

R2019a で導入

参考

SEI CERT-C をチェック (-cert-c)

トピック

外部の Web サイト

CON32-C

¹ This software has been created by MathWorks incorporating portions of: the “SEI CERT-C Website,” © 2017 Carnegie Mellon University, the SEI CERT-C++ Web site © 2017 Carnegie Mellon University, ”SEI CERT C Coding Standard – Rules for Developing safe, Reliable and Secure systems – 2016 Edition,” © 2016 Carnegie Mellon University, and “SEI CERT C++ Coding Standard – Rules for Developing safe, Reliable and Secure systems in C++ – 2016 Edition” © 2016 Carnegie Mellon University, with special permission from its Software Engineering Institute.

ANY MATERIAL OF CARNEGIE MELLON UNIVERSITY AND/OR ITS SOFTWARE ENGINEERING INSTITUTE CONTAINED HEREIN IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This software and associated documentation has not been reviewed nor is it endorsed by Carnegie Mellon University or its Software Engineering Institute.