"最大の効率は、しばしば最小の安全性を孕む。構造を研ぎ澄ますほど、境界は脆弱になる。"

アセンブリによる最適化は、究極の効率化である。
しかし同時にそれは、型安全性、境界チェック、メモリ保護といった高級言語的防御機構を意図的に捨てることでもある。

本章では、アセンブリ最適化がもたらすスピードと制御の快楽と、
それによって生じる安全性との対立構造を掘り下げる。

その設計上の判断は、単なる技術ではなく、倫理と責任を帯びた構造選択でもある。

なぜアセンブリで最適化するのか？

C言語やRustでも最適化は可能だ。
だが、アセンブリによる最適化には次のような魅力がある：

例：

mov eax, [edi]
add eax, [esi]
mov [edi], eax

これをわざわざ書く理由は、**最適化されたCがここに“必ずしも到達しない”**からである。

その最適化、何を犠牲にしているのか？

C言語では、型システム（弱くとも）により、誤った操作をある程度検出できる。

アセンブリでは：

→ プログラマの誤解が即バグとなり、セキュリティホールとなる。

高級言語では：

arr[i] = 10;

が配列サイズを超えると例外や未定義動作となるが、
アセンブリでは：

mov [ecx + edi*4], eax

はあらゆるアドレスに書き込みうる。
→ 意図しない書き換えは、スタック破壊・コード注入の温床となる。

高速化のための命令並べ替え（アウトオブオーダ実行）や、
投機的分岐がCPU側で実行されるが、
この仕組みは「Spectre」「Meltdown」などのマイクロアーキテクチャ攻撃の土台ともなる。

アセンブリでそれを制御するには、厳密な命令順制御とキャッシュ無効化が必要になる。

完全な安全はないが、次のような「慎重なアセンブリ設計」は可能：

→ 安全とは、規律と意図を持った設計の積層である。

sub esp, 0x80
mov eax, [esp+0x88] ; リターンアドレスを越えてアクセス

→ 一見最適化された配列アクセスだが、境界チェックが存在しないことで“コード書き換え”が可能。

アセンブリ命令の断片（ガジェット）を連結し、意図的に攻撃用コードを生成する技法。

→ 本来の最適化命令列が“再解釈され、悪用される”パターンである。

否。むしろアセンブリは、**“全責任を開発者が負う構造”**であり、
最も透明で、最も誠実な言語構造である。

問題は、「その責任を理解しない者が書いたとき」にのみ発生する。

"安全とは、抽象ではなく、制御の総量である。アセンブリはその制御を解放し、同時に問う。お前は、すべてを握る覚悟があるか？"

最適化と安全性は、しばしば対立する。
だがそれは選択肢ではなく、**“設計という態度の中に共存させるべき構造的問題”**である。

アセンブリを使うということは、
制御と責任を同時に引き受け、速度と信頼性の両立を志向するという倫理の選択でもある。

"アセンブリは危険ではない。無知が危険なのだ。最適化とは構造への介入であり、安全とはその介入に対する誠実さである。"