メモリ権限を適用するのになぜそれほど時間がかかったのですか？

Question

[〜＃〜] dep [〜＃〜] のウィキペディアページから。

DEPは、2004年にLinux（カーネル2.6.8 [2]）で、2004年にWindowsでWindows XP Service Pack 2、[3] while Apple = 2006年にx86に移行したときにDEPが導入されました。

DEPがリリースされた2004年まで、ハードウェアでメモリページアクセスフラグを適切に適用するのになぜ時間がかかったのですか？それを困難にしたハードウェアまたはソフトウェアアーキテクチャに制限はありますか？

Polynomial · Accepted Answer

これは主に、ハードウェアメーカー側の費用便益分析の問題であり、OSベンダーに代わってのリスク分析の問題です。

X86アーキテクチャは、80386までさかのぼってメモリページへのアクセス権を提供してきましたが、当時、そのようなハードウェアの適用はハードウェアに実装するのに費用がかかり、必要とは見なされていませんでした。コンピュータは、ほとんどのユーザーとほとんどの中小企業にとってすでに法外に高価であったため、ハードウェアメーカーは、顧客が理解または気にしない機能のためにコストを上げたくありませんでした。

時間が経つにつれて、この自己満足はより明白になりました。バッファオーバーフローの時代が到来し、大企業を傷つけ始めていました。 2003年までに、コンピュータセキュリティは商業的に収益性の高い分野であることが証明され、ハードウェアの価格は商品レベルまで下落しました。 AMDとIntelは最終的に、ハードウェアの実施が有益な機能であると判断したため、2004年の初めにNever eXecute（NX）を実装しました。AMDはNXをサポートするAthlon XP-M "Dublin"をリリースし、それをサポートする最初のIntelプロセッサはPentiumでした。 4プレスコット（リビジョンE0）。ただし、現時点では、NXを搭載したプロセッサの市場シェアはごくわずかでした。

ソフトウェア実装の主な障壁は、NXを使用できるようになる前に、物理アドレス拡張（PAE）を有効にしてサポートする必要があることでした。これは、OSカーネル内のコアメモリ管理に大幅な変更を加えることを意味しました。

ソフトウェア側の問題のもう1つの部分は、アプリケーションの記述が不十分だったことです。一部のコードは、実行可能としてマークされたメモリページに配置されていないデータを誤って実行する機能に依存していました。メモリアクセスフラグのハードウェア強制の出現により、これらのプログラムはアクセス違反をスローします。変更を進める前に、メリットを慎重に検討する必要がありました。ハードウェアサポートのない概念としてのDEPは、以前はLinuxの潜在的な機能と見なされていましたが、複雑さの問題、重大な変更、およびソフトウェア施行メカニズムを簡単にバイパスできるという事実のために却下されました。

ハードウェアサポートが利用可能になると、それを使用するためにオペレーティングシステムを変更する必要がありました。これは簡単な作業ではありませんでした。 DEPは、スタックやヒープなどの特定の重要な構造を実行不可としてマークします。これには、NXをサポートするように変更するスレッドとプロセスの作成を処理するすべての初期化ルーチン、およびメモリ管理への特定の変更（ヒープ割り当てなど）が必要でした。最後に、サポートするプロセッサのNXフラグを正しく認識するために、一部のハードウェア抽象化レイヤーコードを変更する必要がありました。

全体として、これは実際には驚くほど迅速に起こりました。ハードウェアNXの実施が利用可能になると、Windows XPとLinuxの両方が8か月以内にNX互換のビルドをリリースしました。

D.W. · Answer

2つの理由があります：（a）セキュリティが最優先事項ではなかったこと、および（b）32ビットアーキテクチャと64ビットアーキテクチャの違い。

NXビットは、64ビットアーキテクチャでのみサポートされます。 NXビットはページレベルの実行権限を提供するため、オペレーティングシステムは一部のページを実行不可としてマークできます。 NXビットは、特定のページを実行不能にする標準的な方法であるため、DEPを実装するための標準的で最もクリーンな方法です。ただし、64ビットアーキテクチャが普及するまでにはしばらく時間がかかりました。そのため、多くの人が64ビットアーキテクチャを使い始めて初めて、OSにNXビットベースのDEPのサポートを実装することがセキュリティに大きなメリットをもたらしました。

したがって、DEPの実装は、64ビットアーキテクチャの採用が遅いために部分的に遅くなりました。（32ビットIntelプラットフォームがNXビットをサポートしている場合、DEPの以前の展開を見た可能性がありますが、そうではなかったため、サポートしませんでした。）DEPは64ビットIntel/AMDチップまで普及しませんでした。普及しました。そのため、DEPが普及するまでに非常に長い時間がかかりました。

さて、ここで私は、上記が少し単純化しすぎていることを認めます-あまり多くはありませんが。実際、32ビットアーキテクチャにDEPを実装する方法はありますが、それははるかに難しく、現在ほとんどのオペレーティングシステムが構築されている方法とうまく調和していません。

32ビットIntelアーキテクチャには、実際にはtwo異なるメモリ保護メカニズムがあります。ページレベルの保護とセグメントレベルの保護です。ほとんどのオペレーティングシステムは、メモリ保護のためにページレベルのメカニズム（ページテーブルなど）に依存しています。各ページは独自の保護レベルを持つことができるため、ページレベルのメカニズムが最も柔軟性があります（たとえば、読み取り専用と読み取り/書き込み、ユーザーアクセス可能とカーネルのみ）。ただし、32ビットIntelプロセッサは、セグメントベースのメモリ保護もサポートしています。セグメントはメモリの連続した領域であり、いくつかの異なるセグメントを持つことができます。各セグメントは、独自の保護アクセスを受け取ることができます。ページレベルの保護はより柔軟であるため、ほとんどのオペレーティングシステムはセグメントレベルの保護を使用しません（メモリを1つの大きなセグメントとして効果的に扱い、セグメンテーションを開始します）。

なんらかの理由で、32ビットアーキテクチャでは、セグメントレベルの保護ではセグメントを実行不可としてマークできますが、ページレベルの保護メカニズムではページを実行不可としてマークできません。（理由はわかりませんが、おそらく単なる履歴のアーティファクトです。）これは、セグメントレベルの保護を使用して、32ビットアーキテクチャにDEPを実装することが可能であることを意味します。ただし、これにはあらゆる種類のゆがみとオペレーティングシステムの大幅な変更が必要です。そうすることはかなり厄介で複雑になり、パフォーマンスにも影響を及ぼします。このため、多くのオペレーティングシステムは、32ビットアーキテクチャにDEPを実装することを躊躇していました。

したがって、DEPが32ビットアーキテクチャでは不可能であり、最初に64ビットアーキテクチャで可能になったと言うのは正確ではありませんが、エンジニアリングの目的では、かなり真実に近いものです。