アプリとOSは何が違うのか

初級の「アプリはお願いしかできない」、中級の「CPUのモードで強制される」を、上級ではCPUの特権レベルという一段下まで下ろします。

1. CPUは命令を実行するとき、自分が今どの特権レベル※1 にいるかを持っている。大きくカーネルモード（特権）とユーザーモード（非特権）の2つ
2. 入出力ポートへのアクセス、ページテーブルの差し替え、割り込みの制御といった特権命令※2 は、カーネルモードでしか実行できない
3. アプリのコードは常にユーザーモードで走る。ユーザーモードで特権命令を実行しようとした瞬間、CPUは例外を上げ、制御を強制的にカーネルへ移す
4. つまり「触れない」は監視でも善意でもなく、ハードウェアが引いた壁。アプリが部品に用があるなら、この壁を正式な入口から越えるしかない

登場人物メモ（※の説明）:

• ※1 特権レベル — CPUが持つ「今どれだけ強い権限で動いているか」の状態。x86では歴史的にリング0（カーネル）〜リング3（ユーザー）と呼ばれ、実運用ではこの両端だけを使うことが多い
• ※2 特権命令 — 機械全体に影響する危険な命令。ユーザーモードで実行すると例外になり、勝手には通らない

⚠️ イレギュラー（壁の外側にもう1段ある）:

• もっと下の階層 — 仮想マシンを動かすと、OSカーネルの下にさらに強い権限層（ハイパーバイザ）が入る。ゲストOSの「特権」が、ホストから見ると特権でなくなる入れ子構造になる
• 壁に穴があると全部崩れる — この境界の実装にバグがあると、後述の権限昇格でユーザーモードのコードがカーネル権限を得てしまう

壁を越える正式な入口がシステムコールです。上級では「なぜ遅く、なぜ安全なのか」をコストの側から見ます。

1. アプリは番号と引数を決められた作法でセットし、専用のトラップ命令※1 を実行する
2. トラップで特権レベルがカーネルへ上がり、CPUはあらかじめOSが登録した入口（ハンドラ）へジャンプする。アプリが飛び先を自由に選ぶことはできない
3. カーネルは番号から処理を選び、引数を検証してから実行する。ここが「あなたの許可がなければ却下」の検問所
4. 終わったらユーザーモードへ戻し、結果を返す。この一往復に、レジスタ退避やモード切替の段取りが必ず付く

だからシステムコールは、同じプロセス内の関数呼び出しより一桁重い。性能を気にするコードは呼ぶ回数自体を減らす（バッファにまとめてから一度に書く、など）方向に最適化します。安全と速度が同じ「境界を越えるコスト」の裏表になっているわけです。

登場人物メモ（※の説明）:

• ※1 トラップ命令 — ソフトウェアから意図的に例外を起こしてカーネルへ制御を渡す命令。飛び先はOSが握るので、勝手なカーネル内アドレスへは飛べない

⚠️ イレギュラー（境界越えを避ける工夫）:

• 呼びすぎると遅い — 1バイトずつ書くコードは、その都度境界を越えて遅くなる。標準ライブラリのバッファリングは、この越境回数を減らす仕掛け
• 越えずに共有する — 大きなデータの受け渡しは、コピーを避けてメモリ領域を共有する方式（共有メモリ・mmap）で越境コストを削ることがある

初級の「区切り」、中級の「仮想メモリ」を、上級ではアドレス変換のハードウェアまで下ろします。境界は特権レベルだけでなく、アドレス空間でも引かれています。

1. 各プロセスは自分専用の仮想アドレス空間を持つ。どのプロセスも「0番地から自分だけが全部使っている」ように見える
2. 仮想アドレスから物理アドレスへの対応表がページテーブル※1。これはプロセスごとに別々にOSが用意する
3. 実際の変換はCPU内のMMU※2 が命令ごとに行う。自分の表に載っていない物理ページは、そもそもアドレスとして表現できない
4. だから他プロセスのメモリは「踏まないように気をつける」以前に届かない。プロセス切替のたびにOSは使うページテーブルを差し替える（これも特権命令）

登場人物メモ（※の説明）:

• ※1 ページテーブル — 仮想の番地と物理の番地の対応表。ページという固定サイズの単位で管理し、アクセス許可（読み／書き／実行）もここに持つ
• ※2 MMU — Memory Management Unit。CPUに内蔵された住所変換係。変換の高速化のため直近の対応を覚える小さなキャッシュ（TLB）を持つ

⚠️ イレギュラー（分離が効く／揺らぐ場面）:

• 1プロセスがクラッシュしても他は無事 — 不正な番地に触れば、そのプロセスにだけ例外（セグメンテーション違反）が飛び、OSがそのプロセスだけ回収する
• わざと壁の一部を共有する — 共有ライブラリや共有メモリは、複数プロセスの仮想空間から同じ物理ページを指させる。分離が原則で、共有は明示的な例外
• 境界を漏らすハード欠陥 — 投機実行の副作用でアドレス空間の境界越しに情報が漏れる攻撃（Spectre／Meltdown系）は、ソフトの分離が正しくてもハード側から滲む例

プロセスとその中の作業員（スレッド）の関係は プロセスとスレッド で詳しく見ます。

「Windows用アプリはMacで動かない」を、上級では2種類の互換性に分解します。中級で触れた実行ファイル形式とシステムコールの差を、APIとABIという言葉で整理します。

• API（ソース互換の約束）※1 — 関数の名前・引数・戻り値といった、ソースコードから見える約束。これが合っていれば、同じソースを各環境向けに再コンパイルすれば動く
• ABI（バイナリ互換の約束）※2 — 呼出規約（引数をどのレジスタ・スタックに積むか）、構造体のメモリ配置やパディング、実行ファイル形式（PE形式（.exe）／ELF／Mach-O）、システムコール番号といった、コンパイル後のバイナリに焼き込まれる約束。これが合っていれば、再コンパイルせずそのままのバイナリが動く

この2つが分かると、いろいろな現象が一直線に読めます:

1. Windowsのバイナリ（PE形式＋Windowsのシステムコール）はmacOS（Mach-O＋別のシステムコール）とABIが違う。だからそのままでは動かない
2. しかしソース（API）が移植可能なら、Mac向けに再コンパイルすれば動くことは多い
3. 同じOS・同じCPUでも、ライブラリの更新でABIが崩れると、配布済みバイナリだけが突然動かなくなる（ソースを直さずとも壊れる）
4. 互換レイヤーやマルチプラットフォームのランタイムは、このABIの差を吸収する層を1枚挟むことで両対応を実現している

登場人物メモ（※の説明）:

• ※1 API — Application Programming Interface。ソースコードのレベルで「どう呼ぶか」を決める約束
• ※2 ABI — Application Binary Interface。機械語のレベルで「バイナリがどう並び、どう呼び合うか」を決める約束。CPUの命令セットが違えば（例、x86とArm）ABIも当然変わる

⚠️ イレギュラー（互換の綱渡り）:

• APIは同じでもABIが違う — 同じ関数名でも、構造体に項目が1つ増えただけでメモリ配置が変わり、古いバイナリが誤ったオフセットを読む
• CPUが変わるとき — Arm移行時に旧バイナリを動かすため、命令を翻訳する変換層（エミュレータ）を挟むことがある。動くが、翻訳のぶん遅い

境界は「守り」であると同時に、攻撃者が最も狙う一点でもあります。最後に、境界まわりの典型的な破綻を整理します。

• 権限昇格（境界を越えられる） — カーネルやシステムコール処理のバグを突き、ユーザーモードのコードがカーネル権限を奪う。境界の穴は機械全体の支配に直結するので、OSアップデートが最優先になる
• サンドボックス脱出 — ブラウザやコンテナは、アプリをさらに狭い箱に閉じ込める。その箱の壁（多くはカーネルとの境界）に穴があると、箱の外へ出られてしまう
• システムコールのコストを軽視した設計 — 細かい入出力を1回ずつシステムコールで行うと、越境コストが積み上がって遅い。まとめ書き・非同期化・共有メモリで越境回数を減らすのが定石
• ABI破壊に気づかない — ソースを直さずライブラリだけ更新して、配布済みバイナリが静かに壊れる。互換性は「動いているうちは見えない」ぶん、崩れたときの原因が分かりにくい
• 「壁があるから安全」という過信 — 境界はあくまで既知の危険を止める仕組み。ハードの投機実行を突く情報漏洩のように、壁の正しさとは別経路で滲むこともある。多層で守る前提を崩さない

まとめ——アプリとOSの間には、特権レベル（誰が強いか）／システムコール（どう越えるか）／アドレス空間（どこまで届くか）／ABI（バイナリの約束）という何重もの境界が引かれています。速さも、安全も、互換性も、そして攻撃も、すべてこの境界の上で起きている——ここまで見えれば、コンテナ・仮想マシン・サーバ運用の話は、同じ境界を引き直したり重ねたりする応用として読めるようになります。