もし実行の流れを十分にひっくり返して、行くべきじゃない場所にジャンプできるなら、条件分岐よりもバイナリ内で他にもっと良いターゲットがあると思うよ。

多くの開発者は、コードは自己文書化されるべきだと思ってるけど、俺もその意見には賛成だよ。でも残念ながら、実際に自己文書化されたプロジェクトに関わったことはないな。リーダーたちがそう望んでたのにね。

コミットには文脈を入れるのが好きなんだ、コードのコメントじゃなくてね。理由は簡単で、コメントはチェックされないから。例えば「これはジョン・ドーが提案したからこうなってる、こっちの方が効率的だよ」って書いても、他の誰かがコードをバグだらけにしたり、間違ったり、遅くしたりすることがある。そうなると、そのコメントはもう存在しない動作を説明していて、コードが何かを意味していると誤解させることになるんだ。もう一つの理由は、コメントがノイズになるってこと。無駄なコメントが増えれば増えるほど、コア開発者たち（ほとんどのコードを書いて読んでる人たち）はコメントを無視するようになる。そうすると、「XYZがまだ初期化されてないときにこれを呼ばないように気をつけて、ABCが起こるのが気にならないなら」みたいな重要なコメントも無視されちゃって、結局コメントは役に立たなくなる。コミットメッセージは特定の変更に付随してるから、もしコードの行がどうしてそうなってるのか知りたいなら、git blameを使ってどのコミットが原因か、問題番号、著者、レビューア、文脈、履歴なんかを確認できる。もしこのパッチを簡単に説明するコメントが必要なら、多分必要だね。でもコミットメッセージには他の文脈を加えるべきだと思う。

でも、これは意図通りに動いてるの？ コードはドキュメントでごちゃごちゃしてないし、コードを読むときに必ずしも意味があるわけじゃないけど、コミットを読むことでコードがこう書かれた理由がわかるんだ。

え？ 記事からもう少し引用すると: > [W]e find this in ARM.cpp: > trapInstr = {0xd4, 0xd4, 0xd4, 0xd4}; トラップ命令がパディングとして使われていることは説明する必要があるけど、ここからはそれが明らかかどうかはわからないね。実際のコードを開くと[1]、trapInstrの出現はすべて次のように続いている: > void ARM::writePlt( /* ... / ) { > / ... */ > memcpy(buf + 12, trapInstr.data(), 4); // 16バイトの境界にパディングする、これは絶対的にベストではないけど、十分に明確だと思う（もちろんPLTが何かを知っていればね、リンクを作る人なら知ってるべきだ）。伝統的にNOPを使うオプションがASLRを効果的でなくするから、（意図されている）トラップを使っていることを説明する価値があると思う。でも、あなたが引用してるコミットメッセージにはそれも書いてないね。[1] https://github.com/llvm/llvm-project/blob/b20c291baec94ba370...

それは人間の特性だと思う。トーラーは簡潔だけど、タルムードにはたくさんのことが書かれてる。大きなコードベースだと、コメントは膨大になるし、気が散ると思う。実際、元コード監査者として言えるのは、コメントがバグを見つけるのを難しくすることがあるってこと。特定のフレームで考えさせられるからね。俺はコメントなしで監査する方が好きだった。まあ、確かに有効な理由はあるけど、コミットログや開発ノートファイルの方が一般的には好ましいと思う。特に良い名前付けと組み合わせるとね。

記事によると、ARM Thumbでは、トラップとして解釈されるべき命令がトラップせずにジャンプするんだって。

それは悪用できるものじゃない。記事にはそうは書いてないよ。 > 実際には悪用の緩和策なんだ。記事はそれを明確にしてる。 > バグじゃなくて、こういう風に動くのは意図的なんだ。 「こういう風に」って何？ トラップなのかジャンプなのか？ ジャンプがトラップとしてカウントされるべきだと言ってるなら、それはかなりひどいね。まだ多くのジャンプがパディングに続いて、価値のあるコードを実行することを許してるんだから。

その指示は、機能するためにはトラップ命令でなきゃダメだよ。条件付きの逆分岐命令は、NOPの連続と同じくらいダメで、攻撃者を動作するコードにリダイレクトする可能性が高いからね。（もし攻撃者が最初にmiフラグをクリアできたら、これらはただのNOPだし！）だから、そう、これは壊れたエクスプロイト緩和策だね。