現在、ハードウェアによるプロセス分離を使用するアーキテクチャはありますか？それをx86に追加するには何が必要ですか？
初めてのアスカー/コメンター、長年の読者。
コンピューターのセキュリティを根本的に改善する可能性のある対策について、現在多くの考えや執筆をしている人として（つまり、ほとんどの技術者が現在注力している、進化的でかなり控えめなステップだけでなく、「大きな飛躍」を追求している人として変更により、下位互換性が失われる可能性がありますが、システムがmuchより安全になります）。堅牢な一般的なプロセス分離を使用して、ユーザーモードプログラム（または、とにかく、今日「ユーザーモード」プログラムと呼ばれているもの）が、読み込もうとするような厄介なことを実行できないようにしようとする考え方には、私はとても夢中になっています。/stealデータが他のユーザーモードプログラムで使用されているか、特権昇格攻撃でOSを攻撃しています。
現在、ソフトウェアに強力な特権分離スキームを実装しようとした、または実装しようとしている企業/組織は確かに存在します。たとえば、Microsoftの開発Singularity SOこれは、ほぼすべてを「制限された分離プロセス」に入れ、限定されたメッセージパッシング「契約」を介して互いにおよびOSとのみ通信できました。 、軍事/インテリジェンスの高セキュリティシナリオのために政府で使用されているものも含めて、私は理解しています。）しかし、私は根拠のないセキュリティ防御に途方もない信頼を置くことに消極的であると思いますその日、ある種の直接的なハードウェア適用で、2つの（密接に関連する）質問に私を導きます：
第1に、今日、非政府系で商業的に生産されているマイクロプロセッサはありますか？多目的コンピューティング用です。強力なプロセスの分離/分離を強制するために特別に設計された命令セット/アーキテクチャを使用するスマートカードチップなどはありませんか？ （デバイス上で実行されているOSのカーネルに深く発生する欠陥を悪用する攻撃でさえ、プロセス内の悪意のあるコードが分離されないようにするのに十分であるとは言えません。）
次に、x86-64命令セットと対応するチップアーキテクチャにどのような変更を加えて、個々のプロセスの強力なOS分離/分離に対するハードウェア強制サポートを提供できるようにする必要がありますか？
（参考までに、インテルは過去5〜10年間で一部のチップに独自のセキュリティ機能を追加したことを知っています。今年、SGXを搭載したSkylakeは、高セキュリティのニーズを持つ特定のプログラムを分離するための機能を提供することを想定しています。システムの残りの部分です。しかし、今日、ユーザーモードで実行されているすべてのプロセスを最低限ハードウェアで強制的に分離するためには、さらに大きな手順が必要になります。それとも間違っているのでしょうか？）
実際、市場に出ているほとんどすべてのCPUは、低電力組み込みデバイス向けの非常に小さなCPUを除いて、「ハードウェアによる分離」を提供しています。これは [〜＃〜] mmu [〜＃〜] と呼ばれます。総合的に、MMUはアドレス空間を個別のページに分割します（通常はそれぞれ4または8 kB、CPUアーキテクチャとバージョンによって異なります）。また、コードの一部がページにアクセスするたびに、= MMUアクセス権を適用し、アクセスを物理アドレスにマップします（またはそうではありません-これが「仮想メモリ」の仕組みです）。いつでも、CPUはMMU現在のコードが「ユーザーコード」または「カーネルコード」のいずれであるか、およびMMUはその情報を使用して、アクセスが許可されるかどうかを確認します。
各ページのアクセス権と物理アドレスへのマッピングは、メモリ内の特別なテーブルで構成されます。これは、カーネルがMMU（基本的に開始アドレスを物理RAMメインテーブルの専用レジスタにあるMMU構成を切り替えることにより、カーネルはprocessの概念を実装します：各プロセスは独自のアドレスを持っていますスペース、およびカーネルがプロセスにCPUを付与する必要があると判断した場合は、そのプロセスのMMU構成をアクティブな構成にすることで許可します。
これは、これらのことが実現できるのと同じくらいハードウェアで強化されています。 software-only分離の強制が必要な場合は、JavaまたはC＃/。NET：強い型付け、配列の境界のチェック、およびガベージのようなものを見る必要があります。コレクションを使用すると、MMUを使用せずに、コードを分離して同居させることができます。
MMUベースのプロセス分離は、実際にはうまく機能します。プロセスは、他のプロセスのページを変更したり、参照したりすることはできません。これが正しく行われなかった最後の主要なオペレーティングシステムは、Windows-95ファミリでした（2001年に、悪名高いWindows Millenium Editionまで）。
問題は、完全な分離が役に立たないことを理解し始めたときに始まります。アプリケーションプロセスは、ある時点で、ハードウェアと対話し、ファイルを保存したり、ネットワーク経由でデータを送信したり、画像を表示したりできる必要があります。したがって、処理するハードウェアリソースの一貫性と割り当てを維持するアービトレーションシステムの厳密な制御下で、各プロセスの分離されたアドレススペースにデータを流入および流出させる特定のゲートウェイが必要です。その仲裁システムはまさに「オペレーティングシステム」として知られているものです。分離を回避するための「ゲートウェイ」は、しばしばシステムコールと呼ばれます。
現在、OSはソフトウェアであり、バグがあります。それは、すべての重要なソフトウェアにバグがあるためです。これらのいくつかは、悪意を持って書かれたプロセスが他のプロセスに悪影響を及ぼす可能性があります。これは「セキュリティホール」と呼ばれます。ただし、「完全にハードウェアのOS」を作成しても何も解決されません。実際、それはおそらく事態をさらに悪化させるでしょう。ハードウェアにもバグがあります。バグの原因は、開発者がやろうとしていることが複雑であることです。それを行うin hardwareはバグ修正を非常に難しくするだけなので、セキュリティ状況をまったく改善しません。
したがって、プロセス間の分離をより良くするための解決策は、問題にハードウェアを追加しないことです。既に十分なものがあります（そして多すぎるかもしれません）。必要なのは、複雑さの軽減です。これは、システムコールのリストの完全なプルーニングと再設計です。基本的なLinuxカーネルは、300以上の異なるシステムコールを提供します。これは、セキュリティホールを回避しようとするときにlotの作業になります。残念ながら、システムコールを削除すると、既存のコードとの互換性が失われます。
まず、「ハードウェアによる分離」の現在の実装は不十分で弱く見えます。ここにいくつかの「厄介な」質問があります：
- 「特権」モードで実行されているプロセスは、他のすべてのプロセスのデータにアクセスできますか？
- デバイスドライバーは「特権」モードまたは「ユーザー」モードで実行する必要がありますか？どちらのソリューションでも、悪い問題が発生します。「特権」モードで実行されているドライバーは、機密データにアクセスしすぎます。 「ユーザー」モードで実行されているドライバーはデバイスにアクセスする必要があるため、デバイスアクセスをアプリケーションに許可する必要があります。
- すべてのデバイスドライバーのサプライヤーに本当に信頼していますか？
- 最新のOSはすべて、「優れたプログラミング手法」と呼ばれるものが明らかに知られていない時代に由来しています。オープンソースOSのコードをチェックして、そこに多くの（ごめん）混乱を見つけることができます。商用OSの方がはるかに優れていると私たちは信じますか？それは、ソースを確認できないからです。
- 最新のOSは、本当に複雑なソフトウェアです。複雑なソフトウェアの信頼性を向上させる一般的な方法は、その構造です。この構造化は、さまざまなモジュール間のいくつかの強制された「境界」によってサポートされる必要があります。 OSプログラミングでこのような分離をサポート/強制する手段はありません。したがって、OSの設計、サポート、コーディングを行う人々の善意のみを信頼しています。
このリストは継続できます。
私は最近、これらの問題の解決に役立つCPUデザインを探しました。そのようなデザインは見つかりませんでした。