テスト実行率が低い場合の診断

ファジングのパフォーマンスを測る一般的なメトリクスの 1 つは、1 秒間にターゲット バイナリに対して実行されたテストの数です。これは、AFL や libFuzzer などのツールでは、「1 秒あたり実行数」とも呼ばれます。

Info

1 秒あたりのテスト実行数が高い場合、1 秒あたりのテスト実行数が低い場合よりパフォーマンスが高いとみなされます。

ターゲット バイナリに対する 1 秒あたりのテスト実行数はプログラムに依存するため、プログラムによってまちまちです。しかし、Mayhem は、色分けされたしきい値でターゲットのパフォーマンスを示すことで、パフォーマンスの問題がある可能性を警告します。

Mayhem は以下の色によって 1 秒あたりのテスト実行数メトリクスのパフォーマンスしきい値を示します。

• 赤:1 秒あたりテスト実行数は 1 以下です。
• オレンジ:1 秒あたりテスト実行数は 1 を超え 100 未満です。
• 黒:1 秒あたりテスト実行数は 100 を超えます。

1 秒あたりテスト実行数の改善

1 秒あたりテスト実行数に影響を与える要因は、Mayhem インスタンスに割り当てられた CPU や RAM などの演算リソース、対象バイナリに固有の演算の複雑さなど、数多くあります。

特に、Mayhem ターゲットのパフォーマンスが低く、1 秒あたりテスト実行数メトリクスが低い場合、ターゲット バイナリに対して次の診断チェックを行うべきです (該当する場合)。

• sleep または wait 関数を削除します。
• 必須ではない機能/余分な演算を削除します。
• ディスクまたはネットワーク I/O を最小化します。

Note

Mayhem は、アプリケーションをテストする際、ファジング技術を使用して何千 (あるいはさらに多く) というテスト ケースを生成してコンパイル済みのバイナリに入力として送信し、Mayhem ランの期間が終了するまで、それらのテスト ケースが継続的に実行されます。そのため、コード最適化のためにターゲット バイナリに対して複数の変更を加えると、Mayhem ランの 1 秒あたりテスト実行数に複合的な影響を与える可能性があります。

sleep または wait 関数の削除

コンパイル済みのアプリケーションで明示的に sleep または wait 関数を使用している場合、アプリケーションの実行プロセスが意図的に遅らされるため、Mayhem が実行できる 1 秒あたりテスト実行数は少なくなります。

Note

実際、低い 1 秒あたりテスト実行数の原因が sleep または wait 関数である場合、まず、これらの呼び出しを削除する必要があります。そうでなければ、これらの関数は明示的かつ意図的に実行時間を遅らせるため、このガイドに示されている他の最適化メソッドは効果がありません。

そのため、次のように推奨します。

1. ターゲット ソース コードの sleep および wait の呼び出しは実行を遅らせるため、削除します。
2. バイナリ アプリケーションを再コンパイルします。
3. 新しくコンパイルされた sleep または wait 関数の呼び出しがないターゲットの Mayhem ランを再実行します。

Tip

sleep 機能を無効化/抑制するファジング用に最適化された実行モジュールをビルドするビルド設定を用意すると便利でしょう。

必須ではない機能/余分な演算の削除

ターゲットのソース コードの一部がファジングには不要である場合、テスト ハーネスを作成してテスト スコープを限定し、プロセス実行時間を削減することで、1 秒あたりのテスト実行数を増やすことができます。

そのため、次のように推奨します。

1. ファジングに関連する関数またはソース コードの部分を特定します。
2. 特定の関数またはソース コードの部分をファジングするためのテスト ハーネスを作成します。
3. テスト ハーネスを使用して Mayhem ランを実行します。

Tip

libFuzzer ハーネスを使用すると、プロセス実行時間を大幅に削減し、1 秒あたりテスト実行数を増やすことができます。詳細については、チュートリアルの「libFuzzer Harnessing Lab」を参照してください。

ディスクまたはネットワーク I/O の最小化

ディスク/ネットワーク上の場所へのファイル I/O (入出力) を行うアプリケーションは、操作が完了するのを待ってから次の実行プロセスに進みます。そのため、ファイル I/O が実行されるインスタンスは、予想より長い待機時間の原因になり、それによって 1 秒あたりテスト実行数が減少する可能性があります。たとえば、ログ記録は、ファジング用に最適化されたビルドで削除するものの有力な候補です。

Info

特に、Mayhem ターゲットの余分なファイル I/O は、インメモリ tmpfs の限度超過のためにファジング コンテナーが再起動する原因になる可能性があります。これは、処理の遅延をまねき、1 秒あたりテスト実行数を減少させる可能性があります。ファジングの繰り返し時に入力ファイル以外のファイル コンテンツはリセットされないため、余分なファイル I/O は、この処理を望ましい頻度より頻繁に発生させる可能性があります。

そのため、次のように推奨します。

1. ディスクまたはネットワーク I/O を実行するソース コード領域を最小化します (可能な限り)。
2. バイナリ アプリケーションを再コンパイルします。
3. 新しくコンパイルされたディスクまたはネットワーク I/O が最小限のターゲットの Mayhem ランを再実行します。

Tip

オンプレミスで自分のハードウェア上で Mayhem を実行する場合、現実として、ハードウェア自体が制限要因になることがあります。ローカルなディスク スピード (HDD か SSD か)、またはネットワーク スピード (Mbps) が待機時間を長引かせる場合があります。そのため、このような問題が疑われる場合は、自社の管理者に連絡します。

結論

このセクションでは、ターゲットの 1 秒あたりテスト実行数を診断し、増やすためのヒントをいくつか挙げました。上記のリストは、低い 1 秒あたりテスト実行数を分析する際、比較的ありがちな問題を説明しています。それでも、依然としてターゲットの実行が遅い場合は、より詳細にターゲットのパフォーマンスを解析する必要があるでしょう。