さて、私の質問はタイトルにあります
ご存知のように、例外ハンドラー ルーチンは、ユーザー モードをカーネル モードに切り替える責任があります
。これには、特定のアセンブリ命令が含まれます。
そして、これは、アプリケーションがアクセスが制限された高特権の命令とメモリ領域を使用するのを防ぐために行われると主張されています
ユーザー モード アプリケーションは、このユーザー カーネル スイッチを単独で実行できませんか? つまり、アプリケーション自体内の通常の関数ルーチンで、これらのアセンブリ命令を使用しますか?
もしそうなら、ソフトウェア割り込みのポイントと、ユーザーカーネルスイッチに関連するすべてのセキュリティ上の考慮事項を理解できません
そのスイッチをプログラムに実装するだけで、出来上がりです! 今はカーネルモードです
WTH
ポイントはセキュリティです。
ユーザーランド アプリケーションは限られた環境で動作します。彼らは自分のことをすることができますが、明示的に割り当てられていないものを読み書きすることはできません。これはとても重要です。最新の OS 全体のポイントは、アプリケーションを分離しておくことです。これは、ほとんどの場合、最新のハードウェアによって提供されるメモリ マネージャー ユニットを使用することによって保証されます。そのため、典型的なユーザーランド アプリケーションはカーネル メモリにアクセスできず、どこにも「ジャンプ」できません。許可された場合、アプリケーションがカーネルが予期しない場所にジャンプしてコードを実行し、システム全体をクラッシュさせたり、別のアプリケーションからクレジット カード番号を盗んだりしていないかどうかを確認する方法はありません。
アプリケーションが「独自のボックスの外にある」機能を必要とする場合、カーネルコードを呼び出してそれを実行する必要があります。しかし、どのように？アプリケーションの観点からは、カーネル コードのようなものはどこにもありません。そのため、通常、「システム コール」(syscall) には 1 つの命令があります。これにより、現在のコード フローが、カーネルが準備した指定された 1 つの位置にジャンプし、すべてのユーザーランド リクエストを処理することが期待されます。syscall は IRQ、データ/プリフェッチ、および同様のイベントに非常に似ているため、ハードウェア アーキテクチャは通常、「例外」と呼ばれるそのようなイベントと同じようにすべてをモデル化します。したがって、「ソフトウェア割り込み」という名前です。
これは少し単純化されていますが、真実です。真に理解したい場合は、例外、仮想メモリ、および同様の概念に精通している必要があります。
あなたは間違いを犯します: ユーザーができる唯一のことは、特権命令を実行できるルーチンを呼び出すことです。これは、ソフトウェア割り込みによって行われます。呼び出しの処理中に元のユーザー モード プログラムが停止されるため、割り込みと呼ばれます。このように、ユーザー モード プログラムは特別な特権を実行することは完全にできませんが、実行できるカーネルで割り込みルーチンを呼び出すことができます。プログラム自体がカーネル モードになることはありません。
まず、「手動で」カーネルモードに切り替えることで何を得たいのかよくわかりません。それで、あなたは切り替えました、そして何ですか？次に何をしたいですか？ユーザー アプリケーションでアクセスできないはずのリソースにアクセスしたい場合は、アクセスを許可しないことが重要です。アクセスが許可されていると、アプリは次のような厄介なことを簡単に行うことができるからです。
上記のいずれにも関心がない場合、アプリがカーネル特権を取得する理由はありません。
確かに、OS には特定のバグがあり、アクセス権を取得することで回避したいバグと見なされるものがありますが、それはまれであり、重要なものを壊さずにそれらのバグを実際に「修正」できる人はほとんどいません。信頼性とセキュリティに関する懸念は、OS で気に入らないものを「修正」したいという衝動よりも 1000 倍も重要です。
カーネルモードに切り替える方法である割り込みと例外に関しては、それは理にかなっている一般的な実装です。
割り込みはカーネルで処理する必要があるため、必要に応じて切り替えが発生します。割り込みをトリガーするハードウェアをどう処理するかを知っているのは、カーネルとデバイス ドライバーだけだからです。ハードウェアの違いを抽象化し、統一された API をプログラムに提供して、これまたはそのディスプレイ、サウンド カード、ネットワーク カード、またはプリンターなどの操作方法を知る負担から解放することが、OS の要点です。等
ソフトウェア割り込みは、ハードウェア割り込みと同じメカニズムにピギーバックするだけです。ソフトウェア割り込みの主な用途は、OS に何らかの作業/支援を要求することです。当然のことながら、ハードウェア割り込みが既に行っているように、ソフトウェア割り込みも切り替える必要があります。
x86 プラットフォームでは、ハードウェア割り込みとìnt命令は CPU でほぼ同じ応答を返し、非常によく似た方法で処理されます。
このシステム コール機能のために、一部の CPU は割り込みとは関係のない特別な命令を提供します。ハードウェア割り込みの上に実装されたソフトウェア割り込みよりも高速である場合や、ソフトウェア割り込みが提供しない便利な追加機能が付属している場合があります。
これは、x86 命令sysenterとsyscall. これらは、ユーザー モードからカーネル モードへの高速移行用に最適化されています。
一部の例外は、ページ フォールト例外など、ハードウェア割り込みと同じ性質のものです。OSが仮想オンディスクメモリを実装するために使用するメカニズムであるため、カーネルでも処理する必要があります。OS は、ページ フォールトに応答してディスク上のデータにアクセスし、ページ テーブルを変更する必要があります。アプリ自体がそれを実行できる可能性は低く、任意の場所などの重要なものにアクセスできるようにするのは適切ではありません。ディスクまたはページテーブルで自由に。
他の例外は、アプリの実行を制御し、何か問題が発生したことを OS に通知するために使用されます。これにより、OS は、問題を修正するか、不正な動作をしているアプリケーションを終了する機会が与えられます。ゾンビ状態のままにしておく必要はありません。メモリー。これらの例外もカーネルで処理する必要があり、それが唯一の方法です。
ここで、アプリ自体の中でアプリの例外を処理することに関心があるかもしれません。一部のOSではそれが可能です。Linux と Unix は を実装しているのに対し、Windows はそれが呼ぶものStructured Exception Handling(AKA ) を実装しています。通常、どちらを実行しても、最初にカーネルで例外を処理し、次にそれを元の場所に反映する必要があります。これは、ほとんどの CPU が実装されている方法です。このような実装は、例外が最初にカーネルにルーティングされるときに簡単かつ安価に実行でき、カーネルは SEH やシグナルなど、これに加えて何かを実装できるため、何も禁止しません。SEHsignals
とにかく、ユーザー アプリに機能を提供し、セキュリティを確保するのは OS/カーネルであるため、この 2 つが密接に関係している場合が多いためです (OS/カーネルはすべてにアクセスでき、アプリは OS にアクセスすることを想定されていないため)。アプリに代わってこれらのものにアクセスすることがありますが、礼儀を考えてください:)、これらは両方とも、ユーザーモードとカーネルモードの間の架空のフェンスの背後にあります.