Kernel · レッスン 2

権限レベル

processor privilege がユーザー実行と信頼されたカーネル実行を分離する仕組みを学びます。

processor は、機密性の高い instruction と memory access を制限する privilege mode を提供します。Linux はこの hardware boundary を使い、通常の application failure が kernel memory を直接上書きしたり、device を再設定したりできないようにします。privileged execution への遷移はカーネルが制御します。

User Mode

通常の process は、自身の virtual address space 内で user mode として実行されます。自由に計算でき、カーネルが許可した memory mapping へアクセスできます。その範囲は大きくなり得るため、user mode は「少量の memory しか使えない」という意味ではありません。任意の physical memory、別 process の private mapping、privileged processor control へ直接アクセスすることはできません。

page table と protection bit が memory access を強制します。thread が無効または許可されない address を参照すると、processor は kernel へ trap し、カーネルが有効な page fault を解決するか、SIGSEGV などの signal を配送します。

user-mode process が通常直接アクセスできる memory はどれですか？

Kernel Mode

kernel mode では、memory management、scheduling、interrupt handling、driver に必要な privileged instruction の実行と、保護された kernel mapping へのアクセスができます。x86 での Linux の分離は、通常 kernel を ring 0、user process を ring 3 と説明します。Linux は通常、process の一般的な分離に ring 1 と 2 を使いません。

ほかの architecture は exception level など、異なる名前と仕組みを使います。virtualization が加わると、hypervisor と guest の関係は単純な二つの ring の図に収まりません。重要なのは x86 の ring 番号そのものではなく、管理された privilege です。

Linux カーネルを通常実行する x86 protection ring はどれですか？

管理された遷移

いくつかの event が control を kernel entry point へ移します。

system-call instruction が kernel service を要求する
exception が page fault や invalid instruction などの状態を報告する
hardware interrupt が外部 event を報告する

processor は execution context を保存し、設定済み entry mechanism に従って privilege を変え、信頼された kernel code の実行を始めます。カーネルは要求と state を検証し、処理を実行または拒否して、適切な場合は user mode へ戻ります。

application が一時的に kernel code になるわけではありません。CPU がその thread に代わって kernel handler を実行し、kernel が制御する stack と mapping を使います。

system-call transition 中に何が起きますか？

CPU Privilege と User Identity は別物

Linux user root として動く application も通常は user mode で実行されます。UID 0 はカーネルの authorization check に影響しますが、instruction が kernel memory へ直接アクセスできるようにはしません。逆に、kernel code はどのユーザーの system call が原因でも privileged mode で動きます。

capability、namespace、seccomp、security module、cgroup は process が要求できる内容をさらに制限します。この階層型 policy は、hardware の user/kernel mode boundary とは別です。

root identity と kernel mode の比較として正しいものはどれですか？

境界が重要な理由

この境界は通常の bug による被害を限定し、access check を行う地点を提供しますが、kernel vulnerability と malicious module は境界を破れます。信頼された経路で kernel と firmware を更新し、privileged code を最小化し、信頼できない module を読み込まないでください。

speculative-execution issue と side channel も、hardware isolation に継続的な mitigation が必要だと示します。「異なる ring」は土台であって、完全な security proof ではありません。

user/kernel mode の分離はシステム全体のセキュリティを保証しますか？

レッスン完了