/ dev / memとは何ですか？

おそらくそれは何らかの形で記憶に関連しているのでしょうか？何だろう

sudo cat /dev/urandom > /dev/mem

行う？すべてのRAMを破棄しますか？すべての非カーネル仮想メモリ？上記のどれでもない？

システムの物理メモリへのアクセスを提供します。

mem(4)manページには、どのような詳細を説明し/dev/memているが。

はい-それはあらゆる種類の問題を引き起こす可能性があります。再起動すると修正されますが、悪いことが非常に簡単に発生する可能性があります。注意してください！:-)

/ dev / memは、仮想メモリではなく、システムの物理メモリへのアクセスを提供します。カーネルの仮想アドレス空間には、/ dev / kmemを使用してアクセスできます。

主に、ビデオアダプタなどの周辺ハードウェアに関連するIOメモリアドレスにアクセスするために使用されます。

sudo cat /dev/urandom > /dev/memsudoはcatの特権を昇格しますが、リダイレクトの特権は昇格しないため、何もしません。実行sudo suしてからルートシェルで作業するか、または
sudo dd if=/dev/urandom of=/dev/mem

/dev/mem物理メモリ、つまりシステム内のすべてのRAMへのアクセスを提供しますが、これはRAMへの完全な読み取り/書き込みアクセスを提供することを意味しません（このドキュメントのCONFIG_STRICT_DEVMEMオプションを参照）。また、物理メモリの一部の領域には、ビデオカードメモリなどの他のデバイスがマップされることに注意してください。

盲目的に書く/dev/memと、不確実な振る舞いになります。ここに同じことをするyoutubeビデオがあります。

でテストする busybox devmem

busybox devmemmmapsという小さなCLIユーティリティです/dev/mem。

Ubuntuでそれを取得できます： sudo apt-get install busybox

使用法：物理アドレスから4バイトを読み取ります0x12345678：

sudo busybox devmem 0x12345678

0x9abcdef0そのアドレスに書き込みます：

sudo busybox devmem 0x12345678 w 0x9abcdef0

ソース：https : //github.com/mirror/busybox/blob/1_27_2/miscutils/devmem.c#L85

MAP_SHARED

mmapping /dev/memを使用する場合は、おそらく次のものを使用します。

open("/dev/mem", O_RDWR | O_SYNC);
mmap(..., PROT_READ | PROT_WRITE, MAP_SHARED, ...)

MAP_SHARED 書き込みがすぐに物理メモリに送られるため、監視が容易になり、ハードウェアレジスタの書き込みに適しています。

CONFIG_STRICT_DEVMEM そして nopat

/dev/memカーネルv4.9で通常のRAMを表示および変更するために使用するには、次のことを行う必要があります。

• 無効CONFIG_STRICT_DEVMEM（Ubuntu 17.04でデフォルトで設定）
• nopatx86のカーネルコマンドラインオプションを渡す

IOポートはそれらなしでも動作します。

参照：https : //stackoverflow.com/questions/39134990/mmap-of-dev-mem-fails-with-invalid-argument-for-virt-to-phys-address-but-addre/45127582#45127582

キャッシュのフラッシュ

レジスタの代わりにRAMに書き込もうとすると、CPUによってメモリがキャッシュされる場合があります：https : //stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linuxとフラッシュするか、領域をキャッシュ不可としてマークする非常にポータブルで簡単な方法が表示されません。

• https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region-of-address-space-in-linux
• https://stackoverflow.com/questions/885658/is-it-possible-to-allocate-in-user-space-a-non-cacheable-block-of-memory-on-li

それでは、/dev/memメモリバッファをデバイスに渡すために確実に使用できないのでしょうか？

QEMUはキャッシュをシミュレートしないため、残念ながらQEMUではこれを確認できません。

テストする方法

楽しい部分になりました。いくつかのクールなセットアップを次に示します。

• ユーザーランドの記憶
  • volatileユーザーランドプロセスで変数を割り当てる
  • /proc/<pid>/maps+で物理アドレスを取得します/proc/<pid>/pagemap
  • での物理アドレスdevmem2、およびユーザーランドプロセスの反応を監視します。
• カーネルランドメモリ
  • カーネルメモリを割り当てます kmalloc
  • 物理アドレスを取得し、virt_to_physユーザーランドに返します
  • で物理アドレスを変更します devmem2
  • カーネルモジュールから値を問い合わせる
• IOメモリとQEMU仮想プラットフォームデバイス
  • 既知の物理レジスタアドレスでプラットフォームデバイスを作成する
  • devmem2レジスタへの書き込みに使用
  • printf応答として仮想デバイスから出てくるのを見る

/ dev / memは従来、物理アドレス空間全体へのアクセスを提供していました。これにはRAMが含まれますが、メモリマップされたIOデバイスも含まれます。

最新の多くのカーネルは、「CONFIG_STRICT_DEVMEM」で構成され、/ dev / memをメモリマップされたIOデバイスのみに制限します。

ランダムなガベージを書き込むことは悪い考えですが、何が悪いことになるかを正確に予測することは困難です。ハードウェアはランダムなガベージに予測できない方法で応答する場合があり、カーネルメモリ構造が破損すると、カーネルの予測できない動作が発生する場合があります。せいぜいシステムクラッシュが予想されますが、最悪の場合はデータの破損やハードウェアブリックも問題になりません。

PSでは、sudoはリダイレクトではなくcatコマンドのみを進化させるため、通常のユーザーとして実行する場合、コマンドは何もすべきではないことに注意してください。