Clang 対 Clang 対決

 (blog.cr.yp.to)
2 ポイント 投稿者 GN⁺ 2024-08-05 | 1件のコメント | WhatsAppで共有

Clang vs. Clang: Clangを怒らせるな

  • Clangに関する実験を扱ったブログ記事
  • コンパイラ最適化に関連する最近の LLVM および GCC の変更点を見ると、最適化、最適化テスト、テスト修正、バグ修正などが含まれる
  • コンパイラ作者は、自分たちが持ち込んだバグに責任を負いたがらない
  • コンパイラ最適化は実際の性能向上に大きく寄与しない

コンパイラ最適化の問題点

  • 最適化されたコンパイラが性能を向上させるケースはまれである
  • 例えば、kyber768 の avx2 実装は、最適化コンパイラでコンパイルされたコードより 4 倍高速である
  • Todd A. Proebsting の法則によれば、コンパイラ最適化は計算性能にほとんど寄与しない
  • Arseny Kapoulkine のベンチマーク結果も同様の結論を示している

セキュリティ上の問題

  • 最適化されたコンパイラは、従来型のバグだけでなく、タイミングリークのようなセキュリティ問題も引き起こしうる
  • 2018 年の EuroS&P 論文によれば、コンパイラのアップグレードがタイミングチャネルを開き、セキュアなコードを脆弱にする可能性がある
  • Kyber の参照コードでは、Clang 15 以上の最適化オプションでコンパイルされたコードに対する成功したタイミング攻撃が報告されている

TIMECOP ツール

  • TIMECOP 2 は SUPERCOP 暗号テストフレームワークに組み込まれており、秘密から導出された条件分岐を自動でスキャンする
  • TIMECOP 1 と TIMECOP 2 の違い: TIMECOP 2 は RNG の出力を自動で秘密としてマークし、マルチコアで実行される

定数時間コードの記述

  • 定数時間コードの書き方に関する講演を 2024 年 7 月に実施
  • libmceliece と SUPERCOP で提供される定数時間関数を説明
  • 例えば、crypto_uint32_bitmod_mask(x,j) 関数は、コンパイラが 1 ビットの結果を認識できないようにする

コンパイラ最適化問題の予防

  • コンパイラがタイミングリークを持ち込まないようにする予防策の一つは、ライブラリをアセンブリ言語で配布すること
  • しかし、アセンブリ言語はソフトウェアの正しさを監査しにくくする場合がある
  • C、C++ などのコードにタイミングリーク防止コードを迅速に導入する方法を模索中

clang-vs-clang パッチ

  • LLVM 最適化ツールにパッチを書き、&1 と >>31 をスキャンして警告メッセージを出力する
  • 例えば、x >>= 31 のコードで警告メッセージが出力される

結論

  • コンパイラ最適化は性能向上に大きく寄与せず、セキュリティ問題を引き起こす可能性がある
  • TIMECOP のようなツールを使って定数時間コードを書き、コンパイラ最適化の問題を予防すべきである

GN⁺のまとめ

  • この記事は、コンパイラ最適化の問題点とセキュリティリスクを扱っている
  • コンパイラ最適化が実際の性能向上に大きく寄与せず、セキュリティ問題を引き起こしうることを強調している
  • TIMECOP ツールと定数時間コードの書き方を紹介し、セキュリティ問題を予防する方法を提示している
  • コンパイラ最適化問題を予防するため、ライブラリをアセンブリ言語で配布する方法も提案している
  • 関連分野の他プロジェクトとして、FaCT や Jasmin のようなセキュリティ重視のコンパイラがある

関連記事

1件のコメント

 
GN⁺ 2024-08-05
Hacker Newsの意見

  • 最適化によって発生したバグについて、コンパイラ作者は責任を負わない

    • 言語標準によれば、このようなバグはプログラマの誤りと見なされる
    • これはバグではないことの証拠である

  • Bernsteinの意見には同意するが、ときどき間違った方向に進んでいる

    • 最適化の利点はユースケースによって異なる
    • Cコンパイラが、言語で表現できない意味を考慮しないことへの不満がある
    • 「必要な意味を表現できる言語を使え」という結論に要約できる

  • CとC++は、定数時間保証が必要なアルゴリズムを書くのには不向きである

    • 標準にはリアルタイムの概念がほとんどない
    • コンパイラ開発者を非難するのは的外れである

  • Intel CPUでは、clangであれ他の何であれ、ユーザーモードで正しいコードを生成することはできない

    • DOITMを設定することは不可能である

  • コンパイラ作者がバグに責任を負わないという主張には同意しない

    • これはCの基本的な「未定義動作」に対する誤解である

  • clangにはclang::optnone属性があり、関数ごとに最適化を無効化できる

    • GCCにはgnu::optimize属性があり、最適化レベルを設定できる
    • clang::no_builtinsはmemcpyとmemsetの最適化を無効化する

  • Cには未定義動作が多く、他の言語に移行する可能性がある

    • Pythonではsetオブジェクトの順序は重要ではない
    • Cコンパイラはコードパターンを解析して最適化を試みる
    • これはハッブル望遠鏡の問題解決と似たやり方で、より良い性能をもたらすことがある

  • 暗号専門家の目標には同意するが、汎用コンパイラはそれを考慮していない

    • 特化コンパイラが必要になるかもしれない

  • 一部の言語とコンパイラが定数時間の暗号ルーチン作成に不向きなのは事実である

    • すべてのコンパイラとアセンブリ言語が悪いという結論は誤りである
    • 単純なドメイン特化コンパイラと言語を書くべきである

  • 特定の関数例では、SIZE_T_MAX入力時に未定義動作が発生する

    • この種のバグは多いが、実際には重要ではない