すべてのCプログラマーが未定義の動作について知っておくべきこと。 パート2/3

パート1

パート2

パート3



シリーズの第1部では、未定義の動作とは何か、CおよびC ++コンパイラが「安全な」言語よりも高いパフォーマンスのアプリケーションを生成する方法について説明しました。 この投稿では、「安全でない」Cが実際に何であるかについて説明し、未定義の動作によって引き起こされる完全に予期しない影響を説明します。 3番目のパートでは、「友好的な」コンパイラーがこれらの効果の一部を、たとえ必要ではない場合でも、どのように軽減できるかについて説明します。



私はそれを「なぜ不確実な行動がCプログラマーを頻繁に怖がらせ、気遣うのか」と呼ぶのが好きです。

コンパイラーの最適化間の相互作用により、予期しない結果が生じる

最新の最適化コンパイラには、特定の順序で動作する多くの最適化が含まれており、時には複数回繰り返されます。この順序は、コンパイラが開発されると（つまり、新しいリリースがリリースされると）変更される場合があります。



また、コンパイラごとにオプティマイザが大幅に異なります。 最適化はコード変換のさまざまな段階のように機能するため、前の段階でコードが変更されたときにさまざまな効果が発生する可能性があります。



より具体的にするために、そのような愚かな例（Linuxカーネルの実際のバグの例から単純化された）を検討してください。

void contains_null_check(int *P) { int dead = *P; if (P == 0) return; *P = 4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、コードは「明示的に」ヌルポインターをチェックします。 コンパイラが冗長なNull Check Eliminationパスの前に「Dead Code Elimination」パスを開始すると、2つのコード変換が実行されることがわかります。

 void contains_null_check_after_DCE(int *P) { //int dead = *P; // deleted by the optimizer. if (P == 0) return; *P = 4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして：

 void contains_null_check_after_DCE_and_RNCE(int *P) { if (P == 0) // Null check not redundant, and is kept. return; *P = 4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、オプティマイザーの構造が異なる場合があり、DCEの前にRNCEを実行する場合があります。 その後、次の2つの変換が実行されます。

 void contains_null_check_after_RNCE(int *P) { int dead = *P; if (false) // P was dereferenced by this point, so it can't be null return; *P = 4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、冗長コードが削除されます。

 void contains_null_check_after_RNCE_and_DCE(int *P) { //int dead = *P; //if (false) // return; *P = 4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くのプログラマーにとって、関数からnullチェックを削除することは非常に予想外です（そして、彼らはバグをコンパイラのせいにします）。 ただし、contains_null_check_after_DCE_and_RNCEとcontains_null_check_after_RNCE_and_DCEの両方のオプションは、標準に従ってcontains_null_checkの完全に有効な最適化された形式であり、さまざまなアプリケーションのパフォーマンスを向上させるために両方の最適化が重要です。



これは非常に単純で先入観のない例ですが、インライン関数ではこのようなことが常に発生します。 インライン関数は、その後の最適化の多くの可能性を開きます。 これは、オプティマイザーが関数をインライン化することを決定した場合、コードの動作を変更する他のローカル最適化が行われることを意味します。 これは、標準の観点からも実用的な観点からも、生産性を高めるために完全に正しいものです。

不明確な挙動と安全性を混在させないでください

Cに似たプログラミング言語のファミリは、カーネル、setuidデーモン、Webブラウザなど、広範囲の重要な安全なコードに使用されます。このコードは、「敵対的な」入力データおよびそのバグに対応し、あらゆる種類のセキュリティ問題を引き起こす可能性があります。 Cの最も有名な利点の1つは、コードを読むだけで何が起こっているかを比較的簡単に理解できることです。



ただし、不定の動作はこのプロパティの言語を奪います。 たとえば、ほとんどのプログラマは、上記の例の「contains_null_check」がnullをチェックすると想定します。 この例はそれほど怖いものではありませんが（nullが渡されると、このコードは何かを破壊する可能性があり、デバッグ時に比較的簡単に見つけることができます）、実際には完全に正しくない非常に合理的なCコードの断片がたくさんあります この問題は多くのプロジェクト（Linuxカーネル、OpenSSL、glibcなどを含む）に影響を及ぼし、CERTにGCCの脆弱性に関する通知を強制的に公開しました（ただし、 GCCだけでなく、広く使用されている最適化Cコンパイラはすべて脆弱であると個人的に考えています）。



例を考えてみましょう。 注意深く書かれたCコードを想像してください：

 void process_something(int size) { // Catch integer overflow. if (size > size+1) abort(); ... // Error checking from this code elided. char *string = malloc(size+1); read(fd, string, size); string[size] = 0; do_something(string); free(string); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードはチェックを実行して、ファイルから読み取るのに十分なメモリが割り当てられていることを確認し（終端のゼロを追加する必要があるため）、オーバーフロー全体が発生した場合に終了します。 ただし、この例では、コンパイラは（標準に従って）チェックを削除できます。 これは、コンパイラーがコードを次のように変換できることを意味します。

 void process_something(int *data, int size) { char *string = malloc(size+1); read(fd, string, size); string[size] = 0; do_something(string); free(string); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

64ビットプラットフォームでコンパイルが行われる場合、「サイズ」がINT_MAX（おそらくこれはディスク上のファイルのサイズ）であるときにバグが発生する可能性があります。 これがどれほどひどいのか見てみましょう。変数のオーバーフローをチェックするのは合理的だからです。 コードをテストするとき、特にこの実行パスをテストしない限り、問題はありません。 誰かが脆弱性を悪用することを決定するまで、コードは安全であると考えられるようです。 これは非常に予想外の、ひどいクラスのバグです。 幸いなことに、簡単に修正できます。「size == INT_MAX」などを使用してください。



全体をオーバーフローさせることは、多くの理由でセキュリティの問題であることがわかりました。 完全に定義された整数演算（-fwrapvを使用するか、符号なし整数を使用する）を使用した場合でも、整数のオーバーフローに関連する可能性のあるバグのクラスが残ります。 幸いなことに、これらのバグはコードに表示され、セキュリティ監査員によく知られています。

最適化されたコードのデバッグは無意味です

一部の人々（たとえば、生成されたマシンコードを見るのが好きな低レベルの組み込みプログラマー）は、常に最適化を有効にして作業しています。 開発の初期段階でコードにバグがある場合が多いため、これらの人々は、プログラムの実行時にデバッグが困難な問題につながる不均衡な量の予期しない最適化を観察しています。 たとえば、最初の記事の例の「zero_array」の例で誤って「i = 0」をスキップすることにより、コンパイラーがループを完全に削除できるようにします（zero_arrayを「return;」に変更します）。



別の興味深いケースは、グローバル関数ポインターがある場合に発生する可能性があります。 簡略化された例は次のようになります。

 static void (*FP)() = 0; static void impl() { printf("hello\n"); } void set() { FP = impl; } void call() { FP(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どのclangが最適化されますか：

 void set() {} void call() { printf("hello\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、nullポインターの呼び出しが未定義であるため、これを行うことができます。これは、呼び出し（）の前にset（）を呼び出す必要があることを示唆しています。 この場合、開発者はset（）の呼び出しを忘れており、nullを逆参照してもプログラムはクラッシュせず、他の誰かがデバッグビルドを行うとコードが壊れます。



このようなバグは追跡されます。疑わしいものが疑われる場合は、-O0でビルドしてみてください。コンパイラは最適化を実行しない可能性が高くなります。



未定義の動作を使用する「動作する」コードは、コンパイラで何かが変更されると壊れる場合があります。



新しいバージョンのLLVMがコンパイルに使用されたとき、またはアプリケーションがGCCからLLVMに移植されたときに、「動作しているように見える」コードが突然壊れる多くのケースを調べました。 LLVM自体には1つまたは2つのバグがある場合がありますが、ほとんどの場合、コンパイラが原因でアプリケーションに隠されたバグが現れたためです。 これは多くの異なる場合に発生する可能性があります。以下に2つの例を示します。



1.以前は運勢によってゼロと想定されていた初期化されていない変数で、現在ゼロを含まない別のレジスタに配置されています。 この動作は、レジスタアロケータで変更が行われたときに明らかになることがよくあります。



2.スタック上の配列オーバーフローは、「デッド」変数の代わりに実際の変数を上書きします。 これは、コンパイラがスタック上の変数を並べ替える場合、または重複しない有効期間を持つ変数をより積極的にスタック空間にパックする場合に発生します。



重要で恐ろしいことは、未定義の動作に基づくほとんどすべての最適化が将来いつでもバグにつながる可能性があることを見つけることです。 インライン関数、ループの展開、およびその他の最適化はより適切に機能し、それらの大部分は上記のように二次最適化によって行われます。



これは、コンパイラがほとんど必然的に責任を負い始めるという事実と、膨大な量のCコードが爆発を待っている時限爆弾であるということもあり、非常に動揺します。 さらに悪いのは...

大規模なコードベースにUBが含まれていないことを確認する信頼できる方法はありません

これは非常に悪い状況です。実際、大規模なアプリケーションにはUBがなく、将来的に壊れないことを判断する信頼できる方法がないためです。 バグを見つけるのに役立つ便利なツールはたくさんありますが、将来コードが壊れないという完全な自信を与えるものは何もありません。 いくつかのオプション、その長所と短所を見てみましょう。



1. Valgrindは、あらゆる種類の初期化されていない変数やその他のメモリバグを見つけるための素晴らしいツールです。 Valgrindは非常に遅いという点で制限があり、生成されたマシンコードに既に存在するバグのみを検索でき（オプティマイザーによって削除されたものを見つけることができません）、ソースがCで書かれていることを知りません（そしてしたがって、変数のサイズを超える量のシフトや符号付き整数のオーバーフローなどのバグを見つけることはできません 。



2. Clangには実験モード-fcatch-undefined-behaviorがあります。これは、シフト範囲の境界を越える、配列の境界を越えるという単純なエラーなど、違反を探すためのランタイムチェックを挿入します。 これらのチェックは、アプリケーションの速度を低下させ、任意のポインターの逆参照を支援できないため（Valgrindは可能）、制限されますが、他の重要なバグを見つけることができます。 Clangは-ftrapvフラグ（-fwrapvと混同しないでください）も完全にサポートしています。これにより、ランタイムで符号付き整数がオーバーフローするバグをキャッチできます（GCCにもこのようなフラグがありますが、私の経験では非常に信頼性が低く、バグがあります）。 次に、-fcatch-undefined-behaviorの小さなデモを示します。

 $ cat tc int foo(int i) { int x[2]; x[i] = 12; return x[i]; } int main() { return foo(2); } $ clang tc $ ./a.out $ clang tc -fcatch-undefined-behavior $ ./a.out Illegal instruction
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.コンパイラメッセージは、初期化されていない変数や単純な整数オーバーフローなど、バグのクラスを見つけるのに適しています。 主に2つの制限があります。1）コードの実行に関する動的な情報がないこと、2）分析はコンパイル時間を増加させるため、分析は非常に高速であるべきです。



4. Clang静的アナライザーは、より深い分析を行い、ヌルポインターの逆参照など、UBの使用を含むバグを見つけようとします。



通常の警告のような時間制限がないため、コンパイラの警告と比較して、強化された分析ツールと考えることができます。 静的アナライザーの主な欠点は、1）プログラム操作プロセスに関する動的な情報がないこと、2）通常の開発プロセスに統合されていないことです（ただし、XCode 3.2との統合。



5. LLVM「Klee」サブプロジェクトは、記号分析を使用して、コードごとに「考えられるすべての方法を試行」し、コード内のバグを見つけてテストを生成します。 これは、大きなアプリケーションで実行するのが非現実的であるという事実によって主に制限される素晴らしい小さなプロジェクトです。



6.試したことはありませんが、Chucky EllisonとGrigori RosuのC-Semanticsツールは、いくつかのクラスのバグ（シーケンスポイントの違反など）を検出できるという点で非常に興味深いものです。 まだ研究プロトタイプの状態ですが、（小規模および限定的な）プログラムのバグを見つけるのに役立ちます。 詳細については、 John Regerの投稿を読むことをお勧めします。



したがって、バグを見つけるための多くのツールがありますが、アプリケーションにUBがないことを証明する良い方法はありません。 実際のアプリケーションには大量のバグがあり、Cは広範囲の重要なアプリケーションで使用されていると想像してください。これは恐ろしいことです。 前回の記事では、特にClangに注意を払いながら、UBを処理するためにCコンパイラが持つさまざまなオプションを見ていきます。