最近のプログラミングの入門を振り返ってみると、意図的にメモリアドレスをランダムに読み書きするC++プログラムを作成した記憶があります。私は何が起こるのか見たいと思いました。
驚いたことに、私のWindows 98 PCでは、私のプログラムには非常に奇妙な副作用がありました。場合によっては、オペレーティングシステムの設定を切り替えるか、グラフィックの欠陥を生成します。通常、何もしないか、システム全体でクラッシュが発生します。
後で、これはWindows 98がユーザープロセスがアクセスできるターゲットを制限しなかったためであることがわかりました。他のプロセスはもちろん、オペレーティングシステムでも使用されるRAMを読み書きできます。
私はこれがWindows NTの出現に変わったことを理解しています（修正するのに少し時間がかかったと思います）。 Windows では、お客様に属していないプロセスについて RAM を表示できません。
後でLinuxシステムで私のプログラムを実行しましたが、それほど多くの興味深い結果が得られなかったことを思い出してください。私が正しく理解したなら、これは少なくとも部分的にユーザー空間とカーネル空間が分離されているからです。
だから私の質問は次のとおりです。
Linuxがユーザースペースとカーネルスペースを分離しなかった時代はありましたか？つまり、悪意のあるプログラムがLinuxシステムに似たダメージを与えたことはありますか？
ベストアンサー1
Linuxは常にユーザー空間が使用するメモリに直接アクセスするのを防ぎ、プロセスが互いにメモリに直接アクセスするのを防ぎます。プログラムは、カーネルによってマッピングされたメモリにアクセスできる仮想アドレス空間を介してのみメモリにアクセスできます。割り当てられたメモリ外のメモリにアクセスすると、分割エラーが発生します。 （プログラムは、悪名高いおよび/dev/memを含むシステムコールとドライバを介してカーネルにアクセスできます/dev/kmem。また、互いにメモリを共有することもできます。）
MMUはUnix / Linuxカーネル内にありますか？それとも、独自のメモリを持つハードウェアデバイスにのみありますか？今日、Linuxでカーネル/ユーザーの分離がどのように処理されるかを説明しています（以前のバージョンのLinuxではこれを別の方法で処理しました。を参照）。Linuxメモリ管理の概要そして80386 メモリ管理詳細はこちら）。
たとえば、一部のLinux関連プロジェクトでは、これらの分離を排除します。組み込み可能なLinuxカーネルのサブセット8086 CPUと互換性のあるLinuxのサブセットなので、ハードウェアの強制保護を提供しません。µClinuxメモリ管理デバイスを持たない組み込みシステムのサポートを提供します。コアの「コンポーネント」はメインラインカーネルの一部ですが、「PC」アーキテクチャではこの構成は不可能です。