Googleの研究者、Windows NTのカーネル設計は依然としてLinuxを矮小化していると語る

要約:

Microsoft でリバース エンジニアとして 4 年間勤務し、現在は Google で働く研究者ローリー カークは、最近、Windows と Linux の間の数十年にわたる議論を再燃させました。彼女は、Windows NT カーネルはエンジニアリング設計の観点からは依然として「エンジニアリングの奇跡」であり、多くの点で Linux を小さくさえしていると公に述べました。

カーク氏は、彼女が賞賛したのは Windows 11 のスタート メニュー、コパイロット、広告ではなく、Windows の基礎となる NT カーネル アーキテクチャであると強調しました。彼女は、NT は最初から比較的完全なオブジェクト モデルとセキュリティ システムを確立しているのに対し、Linux は従来の Unix をベースに機能、名前空間、SELinux などのセキュリティ メカニズムを徐々に追加してきたため、全体としてより分散しているように見えると考えています。

カーク氏はソーシャル プラットフォームで、プログラマーの観点から最も簡単に説明すると、NT は「オブジェクト指向」設計に近く、最初から非常に強力なセキュリティ モデルを備えていると述べました。対照的に、Linux のセキュリティ機能の多くは、後で徐々に追加されました。彼女は、未来志向のオペレーティング システム カーネルが今日ゼロから設計された場合、最終的な形式はおそらく Linux には似ず、NT に近くなり、BSD ブランチに似たものになる可能性さえあると考えています。

Windows NT は、実際には、現在の Windows 11 を含む 1993 年以降のすべての Windows 主要バージョンの技術基盤です。Microsoft は 1988 年に、以前は DEC で VMS オペレーティング システム開発の責任者を務めていた Dave Cutler を雇用しました。 Microsoft によると、Cutler 氏率いる元 DEC エンジニアの小規模チームは、実際にコードを書き始める前に仕様の開発に約 6 か月を費やしました。当初の目標には、移植性、マルチプロセッサのサポート、C2 レベルのセキュリティ認定が含まれていました。

元マイクロソフト エンジニアの Dave Plummer もディスカッションに参加しました。同氏は、カトラー氏がオペレーティング システムのカーネルをゼロから設計したのは NT が初めてではないと指摘した。カトラー氏はこれまでに RSX-11M と VMS に参加しており、NT は実際にカトラー氏がカーネルをゼロから構築するのは 3 回目です。

ただし、NT は単に VMS を Windows シェルに置き換えるだけではありません。当初は NT OS/2 と呼ばれ、移植性を重視したオペレーティング システムでした。最初は Intel i860 プロセッサ用に開発され、その後 MIPS アーキテクチャに移行されました。 Microsoft は最終的に NT の主要製品の方向性を OS/2 から Win32 に変更しました。重要な背景は、Windows 3.1 がわずか 6 か月で 1,600 万本を販売したことです。

カークが賞賛した中心的なものの 1 つは、NT の「オブジェクト」デザインでした。 Microsoft 独自の技術用語では、NT は従来の意味での C++ などの言語で実装された「オブジェクト指向オペレーティング システム」ではなく、「オブジェクトベース」アーキテクチャを使用します。プロセス、スレッド、ファイル、デバイス、レジストリ キー、ミューテックス、ジョブ、アクセス トークンなどのリソースはすべてオブジェクトとして管理されます。

NT の内部オブジェクト マネージャーは、これらのオブジェクトの作成と破棄、オブジェクトの名前空間の維持、各プロセスが保持するオブジェクトの追跡、および対応するアクセス権の管理を担当します。さまざまなシステム コンポーネントは、オブジェクトが属するコンポーネントが提供するインターフェイスを通じてこれらのオブジェクトを使用するため、基礎となるコンポーネントの内部実装が変更された場合でも、他のコンポーネントへの影響をある程度回避できます。

一般の Windows プログラマーがこの設計に触れる最も簡単な場所は、「ハンドル」です。アプリケーションがファイルを開くとき、Windows はファイル自体をアプリケーションに渡すだけでなく、ハンドルを返し、ハンドルに付与されたアクセス許可を記録します。後でプログラムがファイルを操作するときに、システムはこれらのアクセス許可に基づいてチェックを行います。ハンドルをコピーすると、そのアクセス許可をさらに減らすことができますが、コピー操作によって何もないところからアクセス許可を増やすことはできません。

カーク氏は、さまざまなシステム リソースに対するこの比較的統一された管理方法は非常に洗練されており、NT アーキテクチャの重要な利点の 1 つであると考えています。

NT のセキュリティ モデルも、リソース、ID、および権限に基づいています。ユーザーが Windows にログインすると、システムはユーザーのセキュリティ識別子 SID、ユーザーが属するユーザー グループ、および関連するシステム権限を含むアクセス トークンを作成します。ユーザーが開始したプロセスは通常、対応するアクセス トークンを取得します。また、保護できる各オブジェクトにはセキュリティ記述子があり、これには、どの SID がどのアクセス許可を取得できるか、または拒否する必要があるかを指定するアクセス制御リストが含まれます。

プロセスがオブジェクトにアクセスしようとすると、Windows はアクセス トークンをオブジェクトのアクセス制御リストと照合し、適切な権限を持つハンドルを返します。さらに、セキュリティ記述子には、オブジェクトへのアクセスの成功または失敗を記録する監査目的のシステム アクセス制御リストを含めることができます。

ただし、これは、適切に設計されたカーネルを使用すれば、自動的に絶対的に安全なオペレーティング システムになるという意味ではありません。 Windows NT 3.5はかつてC2のセキュリティ評価を受けていたが、当時の認定環境はネットワーク接続のないスタンドアロンコンピュータで、Microsoftはファイルやレジストリに対するデフォルトの権限も強化した。 Windows がインターネット時代に突入すると、数十年にわたって蓄積されたドライバー、デフォルト構成、互換性要件もシステム セキュリティに大きな影響を与えることになります。

カーク氏の Linux に対する主な批判の 1 つは、Linux がセキュリティと権限管理に複数の連携メカニズムを使用していることです。彼女が提起した質問には、UID、GID、ACL、cgroup、さまざまなセキュリティ ポリシー、SELinux、ファイル システムのアクセス許可などが含まれており、これらのメカニズム間には統一された直観的なアクセス許可の関係図が欠如していると考えられていました。

ただし、この複雑さは Linux の設計方法の一部でもあります。 UID と GID はユーザーとユーザー グループを識別するために使用され、ファイル アクセス許可と ACL はファイルを保護する役割を果たします。機能により、完全な root 権限を取得せずに Web サーバーがポート 80 をバインドできるようにするなど、従来の root アカウントの機能を分離できます。ネームスペースを使用すると、プロセスは独立したファイル システム マウント、プロセス、またはネットワーク環境を参照できるようになります。コンテナテクノロジーはこのメカニズムに基づいて構築されています。 cgroup は、CPU やメモリなどのリソースの使用を制限する役割を担っており、SELinux やその他の Linux セキュリティ モジュールは、これに基づいて追加のセキュリティ ポリシーを課すことができます。

Linux のこれらのメカニズムの多くは、カーネルの開発中に実際に徐々に追加されました。たとえば、SELinux はもともと、2001 年に独立したパッチの形で米国国家安全保障局によって提案されました。その後、Linux は、統一されたカーネル フックを通じてさまざまなセキュリティ モデルにアクセスできるように、Linux セキュリティ モジュール フレームワークを確立しました。現在、Linux カーネルはすでに SELinux、AppArmor、Smack、TOMOYO、Landlock などの複数のセキュリティ メカニズムをサポートしています。

したがって、実際には、2 つのオペレーティング システムの設計思想には大きな違いがあります。 NT は統一オブジェクト モデルを中心に管理を集中化する傾向があるのに対し、Linux は構成可能性にさらに注意を払い、異なるメカニズムに異なるタスクを実行させ、ディストリビューション、管理者、およびアプリケーション シナリオを組み合わせることを可能にします。

カーク氏は、人工知能エージェントが急速に開発されている今日、この違いは特に再検討する価値があると考えています。彼女が提起した中心的な質問は、「AI エージェントには正確に何ができるのですか?」というものでした。

従来のプログラムは通常、ユーザーが明示的に発行した指示に従って 1 つずつ実行されますが、AI エージェントは数分で数千の操作を継続的に実行し、コードを自ら生成して実行し、ファイルを読み取り、複数の権限を連結して複雑なタスクを完了します。したがって、オペレーティング システムは、プログラムを「誰が」実行しているかを判断するだけでなく、AI エージェントがどのリソースにアクセスできるか、どの範囲で動作するか、およびこれらの動作を記録する方法をより明確に定義する必要があります。

カーク氏は、NT のオブジェクト モデルにより、オペレーティング システムがさまざまなリソースに対してより明確な権限関係を確立し、AI エージェントが制御を失った場合に、より集中化された明確な監査記録を提供できると考えています。ただし、これは証明された結論ではなく、まだアーキテクチャ上の仮説であることも認めました。

実際、Linux はこの問題に対してますます多くのツールを提供してきました。 Linux 5.13 で追加された Landlock を使用すると、特権のないプロセスでも、アクセスできるファイル システムとネットワーク リソースをアクティブに制限できます。これらの制限は子プロセスに継承でき、さらに厳しくすることのみが可能であり、子プロセスによって緩和することはできません。 Linux は、seccomp、名前空間、cgroup、およびさまざまな LSM メカニズムと組み合わせることで、AI エージェントを厳密に分離することもできます。

Microsoft 自体も同様の方向に進んでいます。 Microsoft は、2026 Build カンファレンスで Microsoft Execution Containers (MXC) を発表しました。これにより、開発者は AI エージェントがアクセスできるリソースを宣言し、Windows が実行時にこれらの制限を強制できるようになります。 MXC はエージェント用に独立したユーザー アカウントを作成することもできるため、システムはエージェントによって実行される各操作を特定の ID に関連付けることができます。 Windows 11 の既存のエージェント ワークスペースでも、ACL を使用してエージェント アカウントを制限し、エージェントのアクセス許可がユーザーのアクセス許可を超えないようにします。

言い換えれば、Microsoft は現在、SID、アクセス トークン、ACL などの従来の NT メカニズムを使用して、AI エージェントの権限の問題を解決しています。これはまさに、カーク氏が NT アーキテクチャに利点があると信じている点です。ただし、これは Microsoft が Linux に AI エージェント機能がないことを証明したという意味ではありません。 Microsoft自身もAIオペレーティングシステムを進化させている一方で、AIエージェントが新たなマルウェアやセキュリティリスクを生み出す可能性があると警告している。

カークは次に、最も興味深い歴史的代替案を提案しました。それは、Microsoft は当時実際に「Open NT」を立ち上げるべきでした。

彼女が思い描いた Open NT は、GPL ソフトウェアのように完全にオープンである必要は必ずしもありませんが、大企業は Microsoft が設定した基本的なセキュリティと互換性の標準を維持しながら、カーネル内の特定のコンポーネントを変更できます。たとえば、Amazon が初期に EC2 クラウド コンピューティング プラットフォームを構築していたとき、Open NT から「AmazonNT」と呼ばれるバージョンを派生し、Microsoft によって定義されたコア互換性とセキュリティ仕様に準拠しながら、スケジューラ、ネットワーク スタック、またはメモリ アロケータを独自に変更することができました。

実際、Microsoft は過去に同様のモデルをある程度試しました。 Microsoft の共有ソース プログラムは、約 1,600 の企業顧客、大学、政府機関に Windows ソース コードへのアクセスを提供してきました。 2001 年、オーストリア内務省は Windows XP のソース コードを入手した最初のヨーロッパ政府となりました。

2006 年、Microsoft は Windows Research Kernel も発売しました。これにより、大学の研究者は教育や研究のために NT のスケジューラとメモリ マネージャを変更できるようになります。ただし、これらのプロジェクトは依然として本質的に限定的なソース コード共有であり、Amazon などの企業が独自の Windows NT ブランチを作成して商用配布することはできません。

Microsoft が NT をこれ以上開放しない理由について、この記事では、ライセンス収入、知的財産権、技術サポート費用、および Windows 互換性に対する Microsoft の最も重要な取り組みが関係している可能性があると考えています。サードパーティによるカーネルの変更を長期にわたって許可するということは、Microsoft が異なるバージョン間の互換性とセキュリティに関する多数の問題に直面する必要があることを意味する可能性があります。

Linux 開発者は、別の角度から Open NT のビジョンに疑問を抱いています。 Linux カーネル グラフィックス サブシステムの開発に長年携わってきた David Airlie 氏は、本当の問題はカーネル ブランチの維持にかかる長期的なコストであると考えています。ソース コードが完全にオープンであっても、企業が 20 年後も独自の変更されたメモリ マネージャーやスケジューラーを維持する必要がある場合は、専任のエンジニアリング チームに投資し続ける必要があります。

Airlie 氏は、多くの企業が Linux バージョンのフォークを試みてきたが、数年後には自社のブランチを維持するコストが高すぎることに気づき、最終的には変更をメインラインに戻すことを選択することが多いと指摘しました。 Java エコシステム内にさまざまな JVM 実装が長期間存在できる理由は、それらの背後に明確な商用顧客と収益源があるためです。一方、社内企業のみにサービスを提供するノーザンテリトリーの支店では、長期的にそのようなコストを負担するのは難しいかもしれません。

Amazon が NT のスケジューラを変更した場合、Microsoft が毎月リリースするセキュリティ修正を再マージし、テストし、検証する必要があります。時間が経つほど、このブランチは独立して保守する必要があるオペレーティング システム カーネル チームに近づきます。 Linux モデルは、企業が必要とする多数の変更を可能な限りメインラインに戻し、コミュニティ全体が共同で保守するというものです。

ノーザンテリトリー自体に歴史的な重荷がないわけではありません。一部のエンジニアは、VMS の一貫した設計が最新の NT に完全には移行されていないと指摘しました。 Windows レジストリは、エンジニアの間で長い間最も物議を醸しているシステム コンポーネントの 1 つです。

グラフィック システムから別の論争が生じます。 Windows NT 4.0 の時代、Microsoft はグラフィックス パフォーマンスを向上させるために、ウィンドウ マネージャー、GDI、およびグラフィックス ドライバーをカーネル空間に移動しました。これは、重大な問題のあるグラフィックス ドライバーがオペレーティング システム全体のクラッシュを直接引き起こす可能性があることを意味します。 Windows 2000 では、Windows ドライバ モデル、プラグ アンド プレイ、電源管理、WMI、ジョブ オブジェクトなどの多数のメカニズムがさらに追加されました。

したがって、現在の Windows 11 の NT カーネルは、1993 年に NT 3.1 が初めてリリースされたときと同じカーネルではなくなりました。カーク氏が本当に賞賛したのは、最新の Windows のすべての設計が本質的に Linux よりも優れていると考えるのではなく、NT 設立時の基本的なアーキテクチャ コンセプトの一部でした。

歴史的な実績から判断すると、Linux は最終的に、NT が達成できなかったサーバーおよびクラウド コンピューティングの分野での地位を獲得しました。 Linux のオープン ライセンスにより、あらゆる組織がカーネルを変更し、さまざまなハードウェア上で実行し、改善をメインラインに提出することができます。その後のコンテナ、開発ツール、Android などの巨大なエコシステムの出現により、この開発モデルはさらに強化されました。

興味深いのは、Microsoft が近年、Windows で Linux をより快適に実行できるようにするために熱心に取り組んでいることです。 Linux 用 Windows サブシステムは引き続きパフォーマンスとネットワークが向上しており、Microsoft は、ユーザーが Windows 環境で Linux コンテナを直接実行できるようにする WSL コンテナなどの機能もリリースしました。 Google はまた、自社の AI ツールに WSL サポートを追加し始めています。

同時に、Kirk 氏は BSD についても言及しました。彼女は、今日オペレーティング システムのカーネルが再設計されれば、NT に加えて、BSD のようなアーキテクチャも登場する可能性があると考えています。彼女は、BSD の全体的な構造は比較的整っていて、初期の段階では Jails などの分離メカニズムが備わっていると考えています。

FreeBSD Jails はプロセスが認識するファイル システム、ユーザー、ネットワーク環境を制限できますが、Capsicum は Kirk が強調した機能モデルに近いものです。機能モードに入ると、プロセスはグローバル名前空間に自由にアクセスできなくなり、ファイル記述子を通じて明示的に自身に付与されたアクセス許可のみを使用できるようになります。興味深いことに、Capsicum プロジェクトはケンブリッジ大学で完了し、Google から研究資金を受け取っています。

この観点から見ると、Kirk が実際に議論しているのは、すべてのシナリオにおいて Windows と Linux のどちらが優れているかということではなく、より基本的な問題、つまりオペレーティング システムが「アクセス許可」をどのように表現し制御するかということです。

NT のアイデアは、リソースに明確なタイプを持たせ、リソースにアクセス許可を付与し、オペレーティング システムによって可能な限り均一にチェックして記録することです。 Linux は、より柔軟な Unix 基盤から始まり、組み合わせることができる複数のメカニズムを通じてさまざまな環境のニーズに応えます。どちらの方法も単独ではシステムのセキュリティを確保できません。

AI エージェントの出現により、この問題はさらに重要になっています。以前は、オペレーティング システムにとって最も重要な問題は、「どのユーザーが」操作を実行しているかを確認することでした。将来的には、AI エージェントが誰を代表できるか、どのリソースにアクセスできるか、許可が与えられる期間、どのような操作を実行できるか、そしてシステムが何を行ったかを正確に証明できるかどうかについてさらに答えなければなりません。

Windows NT はサーバーおよびクラウド コンピューティングの世界で支配的なプレーヤーにはならず、最終的にその地位は Linux に奪われました。しかし、NT 3.1 の登場から 30 年以上が経過しました。 Windows はオブジェクト、ハンドル、アクセス トークン、ACL の元の設計概念を依然として使用しており、Microsoft は現在、AI エージェントの権限分離の問題を解決するためにこれらのメカニズムを使用し始めています。

したがって、ローリー カークが構想した「オープン NT」は、永遠に架空の歴史の中にのみ存在するかもしれません。しかし、コンピュータが人間に代わってより多くのタスクを積極的に実行し始めるにつれて、ますます現実的な問題がすべてのオペレーティング システムに直面しています。それは、ソフトウェアが人間に代わって動作し始めるとき、どこまでそれを許容すべきでしょうか?