ベースライン

ベースライン

sfill -Illv/dev/urandomパーティションがいっぱいになるまでデータを含むファイルを作成します。このように大きなファイルを作成するには時間がかかります。iotop書き込み速度は約1MB/sと言われます。

ただし、dd if=/dev/urandom >> ./randomfile同じことを行いますが、約12MB / sです。なぜ?sfillはるかに遅いですか?

編集:私はDebian 11 stableを使用しています。 12MB/s のデータが機械式ハードドライブの ntfs パーティションに書き込まれています。 Ext4形式の他の2つのHDを試して、ddを使用して約100MB / sを得ました。sfillしかし、これらのディスクのパフォーマンスはまだ悪いです。

ベストアンサー1

ベースライン

sfillどれくらい遅いか知りたくてベンチマークしました。

信頼していないのでsfill(ソースコードを読んで、国際難読化Cコード大会(何かを安全に実行できると信頼するよく書かれたシステムソフトウェアよりも優れています。)少なくとも仮想マシンで実行して隔離しました。そこで、1GBのループバックマウントXFSを使用してPodmanを介してOCIコンテナで実行しました。ボリュームイメージ:

mkfs.xfs fsimage.xfs
udisksctl loop-setup -f fsimage.xfs
# I get a mountpoint automatically here
sudo mkdir /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
sudo chown testuser:testuser /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
podman run podman run --pull newer --rm -it -v /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test:/data:Z debian:11

私はそれをインストールapt install secure-deleteして実行しましたsfill -Illv /data。システムで実行したhtop結果、11~12MB/sの書き込み速度が観察されました。したがって、約4層の間接参照を使用すると、システムより12倍高速です。

なぜ遅いのですかsfill -Illv

sfillちょうどソースコードを読みました(git repoにチェックインされたアーカイブリンク;ため息...gitのバイナリファイル。セキュリティ担当者は通常、優れたソフトウェアエンジニアではありません。しかし、これはすべての当事者にとって不必要に痛みを伴うものです。)

このソフトウェアは過去20年間愛されておらず、正直なところ、20年前には非常に不潔でした。だからそれは楽しい読書ではありません。

とにかく重要なのは、sfillファイルを開いてデータでいっぱいにして削除することです。

したがって、デフォルトではO_SYNC不特定の理由で – を使用してファイルを開きます。これは恐ろしいパフォーマンスを保証し、最後に単にディスクにフラッシュしない理由はまったくありません。

-f同期書き込みを無効にするには、オプションに1つを追加してください。私の場合、書き込み速度は約130MB / sに速くなりました。

比較すると、cat /dev/urandom > /data/tmpfileこれはほぼ500MB / sです。 1GBの書き込みバッファはそれほど多くのRAMではないため、これは予想されます。

注文する スピード 測定コントラストのスピードアップ
sfill -Illv /data     12MB/秒     12
sfill -Illvf /data   130MB/秒   130
cat /dev/urandom > /data/tmpfile ~ 500MB/秒 ~500

これを読んでみると、実際にCPUに若干のボトルネックが発生し始めたこと、つまり私のカーネルのurandom(反類似)RNGの一部が実際に現れていることがperf top明らかです。cat /dev/urandom > /data/tmpfilechacha_permute

したがって、同期書き込みはまだパフォーマンスの低下を完全に説明していません*buf++ = (unsigned char) (256.0*rand()/(RAND_MAX+1.0))。これは浮動小数点演算を実行するのに不要であるだけでなく、良いランダム性も提供しません。現代のGNU / LinuxシステムではRAND_MAX正確に2 ^ 3なので、31ビットのOKランダム性を得てからひどく壊れていました。そして8ビットの誤ったランダム性を得ました...

教訓を得る

  • 20年後のソフトウェアもパフォーマンスを発揮すると期待しないでください
  • セキュリティ研究者コミュニティでソフトウェア広告を見るたびに、ソフトウェアの品質に注意してください。
  • 時には、より簡単な解決策がより良い解決策です。使用可能なすべてのディスク領域が使い果たされるまで、ランダムに満たされたファイルを作成します。いいえ特別なプログラムが必要ですsfill。ランダムなデータを作成し、ディスクがいっぱいで失敗するまでファイルにパイプし、削除するすべての操作は同じことを行います。
  • Gutmann USENIXの記事は議論の余地がない。比較的一般的な合意は、最新のストレージおよびファイルシステムでは本質的に間違ったツリーを吠えることです。最新のハードドライブは物理学の限界に非常に近いため、以前に書かれた内容と量子理論によって許容される測定によって理論的に正確に読み取れる内容との間の相互情報が低すぎるため、多くの作業を実行できません。したがって、任意のデータで上書きする必要性が疑わしいです。

技術的に言えば、1980年以降のすべてのハードドライブにはいわゆるスクランブラー、これは、0(または1)の長い行を書くことが一定の信号を生成しないように、書き込みヘッドに入る記号を準備します。したがって、磁気媒体の物理学では、「秘密」のデータを任意のビットで上書きすることは不可能です。ゼロで覆うよりも優れています。上書きはよりランダムです。なぜなら、ゼロはランダムデータと同じであり、書き込み前にスクランブルされるからです。しかし、もちろん、スクランブリングシーケンスは本質的に知られているので、実際に前の書き込みにいくつかの残留磁化がある場合は、次のことができます。できるある意味では、これは古いデータに関する追加情報を含む。繰り返しますが、これは今日の物理学に関連する攻撃ではありません。

おすすめ記事