PVS-StudioでQEMUを確認する

QEMUは、かなりよく知られているエミュレーションアプリケーションです。静的分析は、QEMUのような複雑なプロジェクトの開発者がエラーを早期に発見し、一般的にその品質と信頼性を向上させるのに役立ちます。この記事では、QEMUアプリケーションのソースコードで、PVS-Studio静的分析ツールを使用して潜在的な脆弱性とエラーをチェックします。



QEMUは、プラットフォーム間でハードウェアをエミュレートするように設計された無料のソフトウェアです。これにより、ターゲットとは異なるハードウェアプラットフォームでアプリケーションとオペレーティングシステムを実行できます。たとえば、MIPS用に作成されたアプリケーションをx86アーキテクチャで実行できます。QEMUは、ビデオカード、usbなどのさまざまな周辺機器のエミュレーションもサポートしています。このプロジェクトは非常に複雑で注目に値するものであり、静的分析の対象となるプロジェクトであるため、PVS-Studioを使用してコードをチェックすることにしました。

分析について

プロジェクトのソースコードは、githubのミラーから取得できます。プロジェクトは非常に大きく、さまざまなプラットフォーム用にコンパイルできます。コードチェックを簡単にするために、PVS-Studioコンパイル監視システムを使用します。このシステムは、静的分析をほぼすべてのビルドプラットフォームに非常に簡単に統合できるように設計されています。このシステムは、ビルド中のコンパイラ呼び出しの追跡に基づいており、その後のファイル分析のためにすべての情報を収集できます。つまり、ビルドを開始し、PVS-Studioが必要な情報を収集してから、分析を開始します。すべてが簡単です。詳細は上記のリンクにあります。



確認した後、アナライザーは多くの潜在的な問題を発見しました。汎用診断（一般分析）の場合、1940高、1996中、9596低が得られました。すべての警告を確認した後、最初の信頼レベル（高）の診断に焦点を当てることが決定されました。そのような警告はかなり多く発見されましたが（1940）、ほとんどの警告は同じタイプであるか、疑わしいマクロの繰り返し使用に関連しています。たとえば、マクロg_newについて考えてみます。

#define g_new(struct_type, n_structs)
                        _G_NEW (struct_type, n_structs, malloc)

#define _G_NEW(struct_type, n_structs, func)       \
  (struct_type *) (G_GNUC_EXTENSION ({             \
    gsize __n = (gsize) (n_structs);               \
    gsize __s = sizeof (struct_type);              \
    gpointer __p;                                  \
    if (__s == 1)                                  \
      __p = g_##func (__n);                        \
    else if (__builtin_constant_p (__n) &&         \
             (__s == 0 || __n <= G_MAXSIZE / __s)) \
      __p = g_##func (__n * __s);                  \
    else                                           \
      __p = g_##func##_n (__n, __s);               \
    __p;                                           \
  }))

このマクロを使用するたびに、アナライザーは警告V773を発行します（「__p」ポインターの可視スコープがメモリーを解放せずに終了しました。メモリーリークが発生する可能性があります）。g_newマクロはglibライブラリで定義され、_G_NEWマクロを使用し、このマクロは別のマクロG_GNUC_EXTENSIONを使用します。これは、 GCCコンパイラに非標準コードに関する警告をスキップするように指示します。アナライザーの警告を発生させるのはこの非標準コードです。最後から2番目の行に注意してください。一般的に、マクロは機能しています。このタイプの警告は848件ありました。つまり、アラートのほぼ半分がコード内の1か所で発生します。



これらの不要な警告はすべて簡単に削除できますアナライザー設定を使用します。ただし、この記事の執筆中に発生したこの特定のケースが、このような状況に合わせてアナライザーロジックをわずかに変更する理由です。



したがって、警告の数が多いからといって、必ずしもコードの品質が悪いとは限りません。しかし、本当に疑わしい場所がいくつかあります。さて、警告に取り掛かりましょう。



警告



N1V517'if（A）{...} else if（A）{...} 'パターンの使用が検出されました。論理エラーが存在する可能性があります。チェックライン：2395、2397。megasas.c 2395

#define MEGASAS_MAX_SGE 128             /* Firmware limit */
....
static void megasas_scsi_realize(PCIDevice *dev, Error **errp)
{
  ....
  if (s->fw_sge >= MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE) {
    ....
  } else if (s->fw_sge >= 128 - MFI_PASS_FRAME_SIZE) {
    ....
  }
  ....
}

コードでの「魔法の」数字の使用は常に疑わしいものです。ここには2つの条件があり、一見異なるように見えますが、MEGASAS_MAX_SGEマクロの値を見ると、条件が重複していることがわかります。ほとんどの場合、ここにタイプミスがあり、128の代わりに別の番号があるはずです。もちろん、これはすべての「魔法の」数字の問題であり、それらを使用するときに封印するだけで十分です。この場合、マクロと定数を使用すると、開発者に大いに役立ちます。



警告



N2V523「then」ステートメントは「else」ステートメントと同等です。 cp0_helper.c 383

target_ulong helper_mftc0_cause(CPUMIPSState *env)
{
  ....
  CPUMIPSState *other = mips_cpu_map_tc(env, &other_tc);

  if (other_tc == other->current_tc) {
    tccause = other->CP0_Cause;
  } else {
    tccause = other->CP0_Cause;
  }
  ....
}

検討中のコードでは、条件演算子のthen本体とelse本体は同じです。ほとんどの場合、ここにコピーして貼り付けます。ただ、ボディコピーし、その後ブランチ、忘れや修正を。他のオブジェクトの代わりにenvが使用されるべきであると想定できます。この疑わしい場所の修正は次のようになります。

if (other_tc == other->current_tc) {
  tccause = other->CP0_Cause;
} else {
  tccause = env->CP0_Cause;
}

このコードの開発者だけが、実際にどうあるべきかを明確に言うことができます。別の同様の場所：

• V523「then」ステートメントは「else」ステートメントと同等です。translate.c 641

警告



N3V547式 'ret <0'は常にfalseです。qcow2-cluster.c 1557

static int handle_dependencies(....)
{
  ....
  if (end <= old_start || start >= old_end) {
    ....
  } else {

    if (bytes == 0 && *m) {
      ....
      return 0;           // <= 3
    }

    if (bytes == 0) {
      ....
      return -EAGAIN;     // <= 4
    }
  ....
  }
  return 0;               // <= 5
}

int qcow2_alloc_cluster_offset(BlockDriverState *bs, ....)
{
  ....
  ret = handle_dependencies(bs, start, &cur_bytes, m);
  if (ret == -EAGAIN) {   // <= 2
    ....
  } else if (ret < 0) {   // <= 1
    ....
  }
}

ここで、アナライザーは、条件（コメント1）が決して満たされないことを発見しました。ret変数の値は、handle_dependencies関数を実行した結果で初期化されます。この関数は、0または-EAGAINのみを返します（コメント3、4、5）。もう少し高いですが、最初の条件では、retの値を-EAGAIN（コメント2）と照合したため、式ret <0の結果は常にfalseになります。おそらく、handle_dependencies関数は異なる値を返すために使用されていましたが、後で、たとえばリファクタリングの結果として、動作が変更されました。ここでは、リファクタリングを完了する必要があります。同様のトリガー：

• V547式は常に偽です。qcow2.c 1070
• V547式 's-> state！= MIGRATION_STATUS_COLO'は常にfalseです。colo.c 595
• V547式 's-> metadata_entries.present＆0x20'は常にfalseです。vhdx.c 769

警告



N4V557アレイのオーバーランが発生する可能性があります。'dwc2_glbreg_read'関数は値 '[0..63]'を処理します。3番目の引数を調べます。チェックライン：667、1040.hcd-dwc2.c 667

#define HSOTG_REG(x) (x)                                             // <= 5
....
struct DWC2State {
  ....
#define DWC2_GLBREG_SIZE    0x70
  uint32_t glbreg[DWC2_GLBREG_SIZE / sizeof(uint32_t)];              // <= 1
  ....
}
....
static uint64_t dwc2_glbreg_read(void *ptr, hwaddr addr, int index,
                                 unsigned size)
{
  ....
  val = s->glbreg[index];                                            // <= 2
  ....
}
static uint64_t dwc2_hsotg_read(void *ptr, hwaddr addr, unsigned size)
{
  ....
  switch (addr) {
    case HSOTG_REG(0x000) ... HSOTG_REG(0x0fc):                      // <= 4
        val = dwc2_glbreg_read(ptr, addr,
                              (addr - HSOTG_REG(0x000)) >> 2, size); // <= 3
    ....
  }
  ....
}

このコードでは、配列のオーバーランに潜在的な問題があります。構造にDWC2Stateは、アレイ定義glbregを28個の要素（コメント1）からなります。dwc2_glbreg_read関数では、インデックスで配列を参照します（コメント2）。ここで、式（addr --HSOTG_REG（0x000））>> 2（コメント3）がインデックスとしてdwc2_glbreg_read関数に渡されることに注意してください。この関数は[0..63]の範囲の値を取ることができます。これを確信するために、コメント4と5に注意を払ってください。おそらく、ここではコメント4から値の範囲を調整する必要があります。 より類似したトリガー：

• V557アレイのオーバーランが発生する可能性があります。'dwc2_hreg0_read'関数は値 '[0..63]'を処理します。3番目の引数を調べます。チェックライン：814、1050.hcd-dwc2.c 814
• V557アレイのオーバーランが発生する可能性があります。'dwc2_hreg1_read'関数は値 '[0..191]'を処理します。3番目の引数を調べます。チェックライン：927、1053.hcd-dwc2.c 927
• V557アレイのオーバーランが発生する可能性があります。'dwc2_pcgreg_read'関数は値 '[0..127]'を処理します。3番目の引数を調べます。チェックライン：1012、1060.hcd-dwc2.c 1012

警告



N5V575「strerror_s」関数は「0」要素を処理します。2番目の引数を調べます。コマンド-win32.c1642

void qmp_guest_set_time(bool has_time, int64_t time_ns, 
                        Error **errp)
{
  ....
  if (GetLastError() != 0) {
    strerror_s((LPTSTR) & msg_buffer, 0, errno);
    ....
  }
}

strerror_s 関数は、システムエラーコードのテキストによる説明を返します。その署名は次のようになります。

errno_t strerror_s( char *buf, rsize_t bufsz, errno_t errnum );

最初のパラメーターはテキストの説明がコピーされるバッファーへのポインター、2番目のパラメーターはバッファーサイズ、3番目はエラーコードです。コードでは、バッファのサイズとして0が渡されますが、これは明らかに誤った値です。ちなみに、何バイトを割り当てるかを事前に知ることは可能です。strerrorlen_sを呼び出すだけで、エラーのテキスト説明の長さが返されます。この値は、十分なサイズのバッファーを割り当てるために使用できます。



警告



N6V595 nullptrに対して検証される前に、「blen2p」ポインターが使用されました。チェックライン：103、106.dsound_template.h 103

static int glue (
    ....
    DWORD *blen1p,
    DWORD *blen2p,
    int entire,
    dsound *s
    )
{
  ....
  dolog("DirectSound returned misaligned buffer %ld %ld\n",
        *blen1p, *blen2p);                         // <= 1
  glue(.... p2p ? *p2p : NULL, *blen1p,
                            blen2p ? *blen2p : 0); // <= 2
....
}

このコードでは、blen2p引数の値が最初に使用され（コメント1）、次にnullptrがチェックされます（コメント2）。この非常に疑わしい場所は、最初に使用する前にチェックを挿入するのを忘れたようです（コメント1）。修正として、チェックを追加するだけです。

dolog("DirectSound returned misaligned buffer %ld %ld\n",
      *blen1p, blen2p ? *blen2p : 0);

blen1p 引数についてはまだ質問があります。おそらく、それはnullポインターである可能性もあり、ここでもチェックを追加する必要があります。さらにいくつかの同様のポジティブ：

• V595 nullptrに対して検証される前に、「ref」ポインターが使用されました。チェックライン：2191、2193.uri.c 2191
• V595 nullptrに対して検証される前に、「cmdline」ポインターが使用されました。チェックライン：420、425.qemu-io.c 420
• V595 nullptrに対して検証される前に、「dp」ポインターが使用されました。チェックライン：288、294。onenand.c 288
• V595 nullptrに対して検証される前に、「omap_lcd」ポインターが使用されました。チェックライン：81、87。omap_lcdc.c 81

警告



N7V597コンパイラは、「op_info」オブジェクトをフラッシュするために使用される「memset」関数呼び出しを削除する可能性があります。RtlSecureZeroMemory（）関数を使用して、プライベートデータを消去する必要があります。virtio-crypto.c 354

static void virtio_crypto_free_request(VirtIOCryptoReq *req)
{
  if (req) {
    if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
      ....
      /* Zeroize and free request data structure */
      memset(op_info, 0, sizeof(*op_info) + max_len); // <= 1
      g_free(op_info);
    }
    g_free(req);
  }
}

このコードフラグメントでは、op_infoオブジェクトに対してmemset関数が呼び出され（コメント1）、その後op_infoはすぐに削除されます。つまり、このオブジェクトをクリーンアップした後、他の場所では変更されません。これは、コンパイラが最適化プロセス中にmemset呼び出しを削除できる場合とまったく同じです。この潜在的な動作を排除するために、コンパイラーが決して削除しない特別な関数を使用できます。 「プライベートデータを安全にクリアする」の記事も参照してください。N8V610不特定の動作の警告。シフト演算子 '>>'を確認してください。左側のオペランドは負です（ 'number' = [-32768..2147483647]）。 cris.c 2111

static void
print_with_operands (const struct cris_opcode *opcodep,
         unsigned int insn,
         unsigned char *buffer,
         bfd_vma addr,
         disassemble_info *info,
         const struct cris_opcode *prefix_opcodep,
         unsigned int prefix_insn,
         unsigned char *prefix_buffer,
         bfd_boolean with_reg_prefix)
{
  ....
  int32_t number;
  ....
  if (signedp && number > 127)
    number -= 256;            // <= 1
  ....
  if (signedp && number > 32767)
    number -= 65536;          // <= 2
  ....
  unsigned int highbyte = (number >> 24) & 0xff;
  ....
}

変数番号は負になる可能性があるため、ビット単位の右シフトは指定されていない動作です。問題の変数が負の値をとることができることを確認するには、コメント1と2を見てください。異なるプラットフォームでのコードの動作の違いを避けるために、そのような場合は避ける必要があります。



その他の警告：

• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランドは負です（ '（hclk_div --1）' = [-1..15]）。aspeed_smc.c 1041
• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランド '（target_long）-1'は負です。exec-vary.c 99
• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランドは負です（ 'hex2nib（words [3] [i * 2 + 2]）' = [-1..15]）。qtest.c 561

同じタイプの警告もいくつかあり、左側のオペランドとして-1のみが使用されます。



V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランド「-1」は負です。hppa.c 2702

int print_insn_hppa (bfd_vma memaddr, disassemble_info *info)
{
  ....
  disp = (-1 << 10) | imm10;
  ....
}

他の同様の警告：

• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランド「-1」は負です。hppa.c 2718
• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランド「-0x8000」は負です。fmopl.c 1022
• V610未定義の動作。シフト演算子 '<<'を確認してください。左側のオペランド '（intptr_t）-1'は負です。sve_helper.c 889

N9警告



V616 0の値を持つ定数をビット演算で使用されている名前のザ・「TIMER_NONE」を。sys_helper.c 179

#define HELPER(name) ....

enum {
  TIMER_NONE = (0 << 30),        // <= 1
  ....
}

void HELPER(mtspr)(CPUOpenRISCState *env, ....)
{
  ....
  if (env->ttmr & TIMER_NONE) {  // <= 2
    ....
  }
}

TIMER_NONEマクロの値がゼロであることを簡単に確認できます（コメント1）。さらに、このマクロはビット単位の操作で使用され、その結果は常に0になります。その結果、条件ステートメントの本体if（env-> ttmr＆TIMER_NONE）は実行されません。



警告



N10V629'n << 9 '式の検査を検討してください。32ビット値のビットシフトとそれに続く64ビットタイプへの拡張。qemu-img.c 1839

#define BDRV_SECTOR_BITS   9
static int coroutine_fn convert_co_read(ImgConvertState *s, 
                  int64_t sector_num, int nb_sectors, uint8_t *buf)
{
  uint64_t single_read_until = 0;
  int n;
  ....
  while (nb_sectors > 0) {
    ....
    uint64_t offset;
    ....
    single_read_until = offset + (n << BDRV_SECTOR_BITS);
    ....
  }
  ....
}

このコードフラグメントでは、シフト操作が32ビットの符号付きタイプを持つ変数nに対して実行され、次にこの32ビットの符号付き結果が64ビットの符号付きタイプに展開され、符号なしタイプとして、符号なし64ビット変数オフセットに追加されます。式の実行時に、変数nに重要な最上位の9ビットがあるとします。 9ビットのシフト操作（BDRV_SECTOR_BITS）を実行しています）、そしてこれは未定義の動作であり、その結果、最上位ビットのセットビットを取得できます。符号付きタイプのこのビットが符号の原因であることを思い出してください。つまり、結果が負になる可能性があります。 nは符号付き変数であるため、展開時に符号が考慮されます。次に、結果がオフセット変数に追加されます。これらの考慮事項から、式を実行した結果が意図したものと異なる場合があることは容易に理解できます。考えられる解決策の1つは、変数nの型を64ビットの符号なし型、つまりuint64_tに置き換えることです。



同様のトリガーがいくつかあります。

• V629 Consider inspecting the '1 << refcount_order' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. qcow2.c 3204
• V629 Consider inspecting the 's->cluster_size << 3' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. qcow2-bitmap.c 283
• V629 Consider inspecting the 'i << s->cluster_bits' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. qcow2-cluster.c 983
• V629 Consider inspecting the expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. vhdx.c 1145
• V629 Consider inspecting the 'delta << 2' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. mips.c 4341

警告



N11V634「*」操作の優先度は「<<」操作の優先度よりも高くなっています。式で括弧を使用する必要がある可能性があります。nand.c 310

static void nand_command(NANDFlashState *s)
{
  ....
  s->addr &= (1ull << s->addrlen * 8) - 1;
  ....
}

不審な場所です。プログラマーが最初に何をしたかったのか、シフトか乗算かは明確ではありません。ここで間違いがない場合でも、コードをもう一度確認して、ブラケットを正しく配置する必要があります。これは、開発者がアルゴリズムが正しいことを確認するために確認する必要がある場所の1つにすぎません。他のそのような場所：

• V634「*」操作の優先度は「<<」操作の優先度よりも高くなっています。式で括弧を使用する必要がある可能性があります。exynos4210_mct.c 449
• V634「*」操作の優先度は「<<」操作の優先度よりも高くなっています。式で括弧を使用する必要がある可能性があります。exynos4210_mct.c 1235
• V634「*」操作の優先度は「<<」操作の優先度よりも高くなっています。式で括弧を使用する必要がある可能性があります。exynos4210_mct.c 1264

警告



N12V646アプリケーションのロジックを調べることを検討してください。'else'キーワードが欠落している可能性があります。pl181.c 400

static void pl181_write(void *opaque, hwaddr offset,
                        uint64_t value, unsigned size)
{
  ....
  if (s->cmd & PL181_CMD_ENABLE) {
    if (s->cmd & PL181_CMD_INTERRUPT) {
      ....
    } if (s->cmd & PL181_CMD_PENDING) { // <= else if
      ....
    } else {
      ....
    }
    ....
  }
  ....
}

このコードでは、フォーマットによっての使用判断した場合、他の代わりの場合は、直接自分自身を示唆しています。おそらく彼らはここに他を追加するのを忘れていました。その場合、修正オプションは次のようになります。

} else if (s->cmd & PL181_CMD_PENDING) { // <= else if

ただし、このコードではすべてが正常である可能性があり、プログラムテキストのフォーマットが正しくないため、混乱を招きます。その場合、コードは次のようになります。

if (s->cmd & PL181_CMD_INTERRUPT) {
  ....
}
if (s->cmd & PL181_CMD_PENDING) { // <= if
  ....
} else {
  ....
}

警告



N13V773「ルール」ポインタを解放せずに関数が終了しました。メモリリークが発生する可能性があります。blkdebug.c 218

static int add_rule(void *opaque, QemuOpts *opts, Error **errp)
{
  ....
  struct BlkdebugRule *rule;
  ....
  rule = g_malloc0(sizeof(*rule));                   // <= 1
  ....
  if (local_error) {
    error_propagate(errp, local_error);
    return -1;                                       // <= 2
  }
  ....
  /* Add the rule */
  QLIST_INSERT_HEAD(&s->rules[event], rule, next);   // <= 3
  ....
}

このコードでは、ルールオブジェクト（コメント1）が選択され、後で使用するためにリストに追加されます（コメント3）が、エラーが発生した場合、関数は以前に作成されたルールオブジェクト（コメント2）を削除せずに戻ります。ここでは、エラーを正しく処理する必要があります。以前に作成したオブジェクトを削除してください。そうしないと、メモリリークが発生します。



警告



N14V781'ix 'インデックスの値は、使用後にチェックされます。おそらく、プログラムロジックに誤りがあります。 uri.c 2110

char *uri_resolve_relative(const char *uri, const char *base)
{
  ....
  ix = pos;
  if ((ref->path[ix] == '/') && (ix > 0)) {
  ....
}

ここで、アナライザーは潜在的な範囲外の配列を検出しました。最初に、インデックスixのref-> path配列の要素が読み取られ、次にixが正しいかどうかがチェックされます（ix> 0）。ここでの正しい解決策は、これらのアクションを逆にすることです。

if ((ix > 0) && (ref->path[ix] == '/')) {

そのような場所がいくつかありました：

• V781'ix 'インデックスの値は、使用後にチェックされます。おそらく、プログラムロジックに誤りがあります。uri.c 2112
• V781「オフセット」インデックスの値は、使用後にチェックされます。おそらく、プログラムロジックに誤りがあります。keymaps.c 125
• V781'quality '変数の値は、使用後にチェックされます。おそらく、プログラムロジックに誤りがあります。チェックライン：326、335.vnc-enc-tight.c 326
• V781'i 'インデックスの値は、使用後にチェックされます。おそらく、プログラムロジックに誤りがあります。mem_helper.c 1929

警告



N15V784ビットマスクのサイズが第1オペランドのサイズよりも小さい。これにより、上位ビットが失われます。cadence_gem.c 1486

typedef struct CadenceGEMState {
  ....
  uint32_t regs_ro[CADENCE_GEM_MAXREG];
}
....
static void gem_write(void *opaque, hwaddr offset, uint64_t val,
        unsigned size)
{
  ....
  val &= ~(s->regs_ro[offset]);
  ....
}

このコードは、さまざまなタイプのオブジェクトに対してビット単位の操作を実行します。左側のオペランドは引数valで、これは64ビットの符号なしタイプです。32ビットの符号なしタイプを持つオフセットインデックスでの配列要素s-> regs_roの受信値は、右オペランドとして使用されます。右側の操作の結果（〜（s-> regs_ro [offset]））は、32ビットの符号なしタイプであり、ビット単位の乗算の前に、ゼロのある64ビットタイプに拡張されます。つまり、式全体を評価した後、val変数のすべての上位ビットがゼロになります。そのような場所は常に疑わしいように見えます。ここでは、開発者にこのコードを再度改訂することをお勧めすることしかできません。より類似：

• V784ビットマスクのサイズが第1オペランドのサイズよりも小さい。これにより、上位ビットが失われます。xlnx-zynq-devcfg.c 199
• V784ビットマスクのサイズが第1オペランドのサイズよりも小さい。これにより、上位ビットが失われます。soc_dma.c 214
• V784ビットマスクのサイズが第1オペランドのサイズよりも小さい。これにより、上位ビットが失われます。fpu_helper.c 418

警告



N16V1046操作「＆=」での「bool」タイプと「unsignedint」タイプの安全でない使用。helper.c 10821

static inline uint32_t extract32(uint32_t value, int start, int length);
....
static ARMVAParameters aa32_va_parameters(CPUARMState *env, uint32_t va,
                                          ARMMMUIdx mmu_idx)
{
  ....
  bool epd, hpd;
  ....
  hpd &= extract32(tcr, 6, 1);
}

このコードでは、ビット単位のAND演算がで実行されたHPDの可変型BOOLと実行結果extract32の機能型有し、のuint32_tを。ブール変数のビット値は0または1のみであるため、extract32関数によって返される最下位ビットがゼロの場合、式の結果は常にfalseになります。例を挙げてこれを見てみましょう。hpdがtrueで、関数が2を返すと仮定します。つまり、バイナリ表現では、操作は01＆10 = 0のようになり、式の結果はfalseになります。ほとんどの場合、プログラマーは値をtrueに設定したいと考えていました関数がゼロ以外のものを返した場合。どうやら、関数の結果が次のようにboolタイプにキャストされるように、コードを修正する必要があります。

hpd = hpd && (bool)extract32(tcr, 6, 1);

結論

ご覧のとおり、アナライザーは多くの疑わしい場所を見つけました。おそらく、発見された潜在的な問題はまだ明らかにされていませんが、最も予期しない瞬間に発火する可能性があるため、その存在は憂慮すべきです。不審な場所をすべて事前に確認して修正する方が、無限のバグを修正するよりも優れています。明らかに、このような複雑なプロジェクトの場合、特に定期的なプロジェクトレビューを組織する場合、静的分析は具体的なメリットをもたらす可能性があります。プロジェクトでPVS-Studioを試してみたい場合は、このページでアナライザーをダウンロードして無料の試用キーを入手できます。

この記事を英語を話す聴衆と共有したい場合は、翻訳リンクEvgeniyOvsannikovを使用してください。PVS-Studioを使用してQEMUを確認します。