これは正確に何をするのですか？これでどのように基本メモリにアクセスするのか理解できないのですが… ちょっと変なようです。安全ですか？
dd if=/dev/urandom of=/dev/mem
ベストアンサー1
自宅でこれをしないでください！システムがクラッシュして運が悪くなると、周辺機器が損傷したり、コンピュータを起動できなくなる可能性があります。
実際、ほとんどのプラットフォームではエラーが原因で失敗しますが、これはハードウェアアーキテクチャによって異なります。権限のないユーザーでコマンドを実行しない限り、これが無害であるという保証はありません。権限のないユーザーの場合、このコマンドは開くことができないため、まったく無害です/dev/mem。
rootでコマンドを実行するときに何をしているのかを知る必要があります。カーネルは時々危険なことはできませんが、必ずしもそうではありません。/dev/mem自分が何をしているのかを知っておくべき潜在的に危険なことの一つです。
/dev/memLinuxでwrite toがどのように機能するかを説明します。一般的な原則は他のUnicesでも同じですが、カーネルオプションのようなものはまったく異なります。
プロセスがデバイスファイルを読み書きするときに何が起こるかは、カーネルによって決まります。デバイスファイルにアクセスすると、デバイスファイルを処理するドライバの一部のコードが実行されます。たとえば、/dev/mem呼び出し関数を作成します。write_mem存在するdrivers/char/mem.c。この関数は、開かれたファイルを表すデータ構造、書き込むデータへのポインタ、書き込むバイト数、ファイルの現在位置など、4つのパラメータを使用します。
呼び出し元が最初にファイルを開く権限を持っている場合にのみ、これを行うことができます。デバイスファイルは通常ファイル権限に従います。一般権限はの所有である/dev/memため、ルートなしで書き込み用に開こうとすると、「権限拒否」（EACCESS）メッセージが表示されます。ただし、あなたがrootの場合（またはrootがファイルに対する権限を変更した場合）、開くプロセスが完了して書き込みを試みることができます。crw-r-----root:kmem
関数のコードはwrite_memいくつかの完全性チェックを実行しますが、これらのチェックだけではすべての悪いことから保護するのに十分ではありません。最初にすることは、現在のファイルの場所を*ppos物理アドレスに変換することです。失敗した場合（実際には32ビットの物理アドレスを持つプラットフォームにありますが、ファイルオフセットが64ビットでファイルオフセットが2 ^ 32より大きいため）、EFBIG（ファイルが大きすぎる）は書き込みに失敗します。 。次の確認は、書き込まれる物理アドレス範囲がこの特定のプロセッサアーキテクチャで有効かどうかです。失敗すると、誤ったアドレス（EFAULT）が発生します。
次に、Sparcとm68kは、最初の物理ページに記録されているすべての部分を自動的にスキップします。
私たちは今到達しましたメインループブロックに入ることができるデータを繰り返します。メモリ管理ユニットページ。
/dev/mem仮想メモリではなく物理メモリにアクセスするがメモリにデータをロードして保存するプロセッサコマンドは仮想アドレスを使用するため、コードは物理メモリが一部の仮想アドレスにマッピングされるように準備する必要があります。 Linuxでは、プロセッサアーキテクチャとカーネル構成に応じて、このマッピングを永続的または動的に作成する必要があります。xlate_dev_mem_ptr（そしてあなたがしたことをすべてunxlate_dev_mem_ptrキャンセルします）。xlate_dev_mem_ptrその後、関数はcopy_from_userシステムコールに渡されたバッファからデータを読み取り、write現在の物理メモリにマップされている仮想アドレスに書き込みます。コードは一般的なメモリストレージ命令を発行し、これはハードウェアによって意味が異なります。
物理アドレスへの書き込みについて説明する前に、書き込み前に発生する確認について説明します。ループ内でpage_is_allowedカーネルがオプションを構成する場合、関数は特定のアドレスへのアクセスをブロックします。CONFIG_STRICT_DEVMEM有効（デフォルト）：許可されたアドレスのみdevmem_is_allowedアクセス可能です/dev/mem。それ以外の場合は、操作が許可されていない（EPERM）ため、書き込みは失敗します。このオプションの説明は次のとおりです。
このオプションがオンになっていてIO_STRICT_DEVMEM = nの場合、/ dev / memファイルはPCIスペースとBIOSコードとデータ領域へのユーザースペースアクセスのみを許可します。これはDosemuとXと/dev/memのすべての一般ユーザーにとって十分です。
これは非常にx86中心的な説明です。実際、より一般的には、CONFIG_STRICT_DEVMEMRAMにマップされた物理メモリアドレスへのアクセスはブロックされますが、RAMにマップされていないアドレスへのアクセスは許可されます。許容される物理アドレス範囲の詳細はプロセッサアーキテクチャによって異なりますが、カーネルとユーザーモードのプロセスデータを格納するRAMはすべて除外されます。追加オプションCONFIG_IO_STRICT_DEVMEM（Ubuntu 18.04以降は無効です）ドライバが宣言した物理アドレスへのアクセスをブロックします。
RAMにマップされた物理メモリアドレス。もしそうなら、RAMにマップされていない物理メモリアドレスがありますか？はい。これがアドレスに書くことが何を意味するのか、上記で私が約束した議論です。
メモリ記憶命令が必ずしもＲＡＭに書き込まれるわけではない。プロセッサはアドレスを確認し、ストレージを転送する周辺機器を決定します。 （私が「プロセッサ」と言うときは、同じメーカーではないかもしれないペリフェラルコントローラを意味します。）RAMはこれらのペリフェラルの1つにすぎません。スケジューリングの実行方法はプロセッサアーキテクチャによって大きく異なりますが、基本原則はすべてのアーキテクチャでほぼ同じです。プロセッサは、基本的にアドレスの上位ビットを分解し、ハードコーディングされた情報、特定のバスを検索して得られた情報、およびソフトウェアで構成された情報に基づいて埋め込まれたいくつかのテーブルでそれを見つけます。多くのキャッシュとバッファリングが関係するかもしれませんが、簡単に言えば、分解後にプロセッサは何かを書き込みます（ターゲットアドレスと格納されているデータエンコーディング）。バスその後、これを処理するのは周辺機器によって異なります。 （またはテーブルルックアップの結果、そのアドレスに周辺機器がない可能性があります。この場合、プロセッサ入力はトラップステータスカーネルでいくつかのコードを実行し、通常は次のような結果が得られます。信号バス電話手順のため。 )
RAMにマップされたアドレスのストレージは、以前にそのアドレスに保存されている値を上書きする以外に何も「実行」せず、後で同じアドレスにロードすると、最後に保存された値が返されることを約束します。しかし、RAMにもこのように動作しないアドレスがあります。登録するリフレッシュの頻度や電圧などを制御できます。
通常、ハードウェアレジスタの読み書きは、ハードウェアが実行するようにプログラムされたすべてのタスクを実行します。ハードウェアへのほとんどのアクセスは次のように動作します。ソフトウェア（通常はカーネルコード）はいくつかの物理アドレスにアクセスし、プロセッサを周辺機器に接続するバスに到達し、周辺機器がその動作を実行します。一部のプロセッサ（特にx86）には、メモリのロードとストレージとは別に周辺機器への読み書きを実行する独立したCPU命令がありますが、x86でも多くの周辺機器はロード/ストアを介してアクセスされます。
このコマンドは、dd if=/dev/urandom of=/dev/memアドレス0（および書き込みが成功する限り後続のアドレス）にマップされた周辺機器にランダムデータを書き込みます。実際、多くのアーキテクチャでは、物理アドレス0にマッピングされた周辺機器がないかRAMがないため、最初の書き込み試行が失敗することが予想されます。ただし、アドレス0にマップされた周辺機器がある場合、または別のアドレスに書き込むようにコマンドを変更すると、周辺機器で予測不可能ないくつかの条件が発生します。アドレスが常にランダムなデータを追加すると、興味深い操作を実行する可能性はありませんが、原則としてコンピュータをシャットダウンすることができます（実際にこれを実行するアドレスがある可能性があります）、一部のBIOS設定を上書きして起動できないようにする作成し、さらにいくつかの問題を引き起こす可能性があります。故障した周辺機器が損傷する可能性があります。
alias Russian_roulette='dd if=/dev/urandom of=/dev/mem seek=$((4096*RANDOM+4096*32768*RANDOM))'