一般的なメモリというより、近年の一般的なOSではそうなっています。
例えば、Windowsでの物理メモリ管理の説明が、PDC10: Mysteries of Windows Memory Management Revealed: Part Two [msdn.com]にあります。
開放されたページはFree Page Listに繋がれて、暇な時やページが必要な時にZero Page ThreadがゼロクリアしてZero Page Listに繋ぎ、再度必要になるとZero Page Listから取ってプロセスに渡されます。
Diablo IIIは? (スコア:0)
これ、一番問題なのはDiablo IIIなのでは?
確保したメモリをクリアせずに使っているってことですよね?
ドライバ(か、あるいはDirect3D?)は解放されたメモリをクリアしておくべきだし、
Chromeみたいなセンシティブな情報を扱うアプリはメモリ解放前にクリアしたほうがいいのは確か。
でも、Diablo IIIが使用前にメモリをクリアしないのはバグだよね。
Re: (スコア:0)
メモリクリアは高コストなのでGPUドライバが一々消さないのは当然。
Chromeはシークレットモード時にはちゃんと消すべきだとは思うが、
不正終了とかも考えると保証できないのであてにすべきではない。
ディアブロがフレームバッファをクリアしないのがタコなのには同意。
だが、Chromeのシークレットモードの都合までは知ったこっちゃないよね。
結局ユーザーがシークレットモードを過信せず自衛するしかないのでは。
Re:Diablo IIIは? (スコア:0)
Chromeの終了の時点でカーネル(OSとドライバ)が使用メモリをゼロクリアするべきですよ。
一般的なメモリでは、当然そうなってます。VRAMがどうなってるかまでは知りません。
Re: (スコア:0)
一般的なメモリでは、当然そうなってます。
あなたの書くプログラムでは確保したメモリや変数領域はOSが初期化してくれるのを前提としてるわけですね?
どこの世界の「一般的」なのか後学の為に教えて下さい。
Re:Diablo IIIは? (スコア:1)
例えば、Windowsでの物理メモリ管理の説明が、PDC10: Mysteries of Windows Memory Management Revealed: Part Two [msdn.com]にあります。
開放されたページはFree Page Listに繋がれて、暇な時やページが必要な時にZero Page ThreadがゼロクリアしてZero Page Listに繋ぎ、再度必要になるとZero Page Listから取ってプロセスに渡されます。
Re: (スコア:0)
「Chromeの終了の時点で」は「Diablo IIIがメモリ確保する時点で」の間違いでした。初期化されるというソースは以下に。
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch11b.html [atmarkit.co.jp]
>mmap()やbrk()などのメモリ確保システムコールには、manページに書かれていない重要なお約束があります。
>それは「確保されたページはゼロ初期化してからユーザー空間に返さないといけない」ということです。
>カーネルは、自分が使わないページにどんなゴミが入っていても気にしないし、ユーザー空間アプリもmalloc()の戻りアドレスがゼロ初期化されていることなん
Re: (スコア:0)
「OSがちゃんとクリアしておくのが当然で、そうしておけば情報流出は防げた」
「(確保したメモリが初期化されているという)仕様外の動作を前提にプログラムを書くのか?」
これ、かみ合ってるようで全然かみ合ってない話だよねー。
Re: (スコア:0)
> この関数によって割り当てられたメモリは、0 に初期化されます。
ちゃんと仕様内の動作やないけ…
Re: (スコア:0)
malloc(3) と勘違いしてない?
brk(2), sbrk(2) でメモリを増やす方に確保したら、その領域は 0 で埋まっていることが保証されている。これ [opengroup.org] の 92ページ目(p.64) の Description をみたら良い。
malloc には mmap(2) を使う実装もあるが、これに渡す file descriptor は、普通 /dev/zero をopen したものを渡す、つまり、最初に使うメモリは 0 で埋められている。
ただし、malloc は一度 OS から確保したメモリを(free(3) されたら)再利用する場合もあるから、その場合は 0 で埋められているとは限らない。
Re: (スコア:0)
さすがに汎用機でも、OSから渡されたメモリーは初期化されてたと思う。
プロセス内で使いまわされる領域の話とはまた別ですよ。
Re: (スコア:0)
そのVRAMの問題なのに…。
セキュアなデータを解放前に消去するのは常識でしょ。
Re: (スコア:0)
バグに関しては、クリアするしないにしろ、仕様書よんでない言い訳ではないのか?
どっちの仕様が妥当かは、OSやドライバーが
クリアしない派は、メモリクリアコストって書いてるけど
クリアすべき派は、「当然」なので理由が書いていませんが
無知な私に、具体的に教えて頂けませんか?
Re:Diablo IIIは? (スコア:1)
>クリアすべき派は、「当然」なので理由が書いていませんが
簡単に結論を書けば、「当然ではない」ということになるかと思います。
あと、ページ単位でのメモリ確保と、ヒープメモリの確保、そしてVRAMの確保では、それぞれ意味が異なり「どうすべきか」も異なってきます。
更に、OSのポリシーによっても変わりうることですから(規格として決まっている部分については別)、それらを一緒くたに語っている時点で間違えているわけです。
付け加えると、VRAMのメモリクリアは、システムメモリ(メインメモリ)のメモリクリアとはコストが異なります。
(例えば、GPUパイプラインを停止させてしまうかもしれません。VRAM確保のたびにコレが発生すると極端なパフォーマンス低下の可能性があります)
ですから、セキュアな処理を必要とするアプリのみでアプリ側が解放前に削除する、というのが現時点では現実解ではないかと個人的には思います。
Re: (スコア:0)
マルチユーザマルチタスクOSでは、OSのポリシーによって変わりうるなんて言ってられないと思います。
異なるプロセス間で物理メモリの内容を共有できるとなれば、情報漏えいを招く脆弱性になりますから。
物理メモリが主記憶だろうがVRAMだろうが同じこと。
他のプロセスが使っているメモリ(データ)を保護するのと同様に、他のプロセスが使っていたメモリ(データ)も保護されないといけない。
Re:Diablo IIIは? (スコア:1)
前者はマルチタスクOSに一般的な保護機能。後者はセキュアに関することですから。
当然、VRAMがあるプロセスに使用されている間は(プライマリサーフェスが画面キャプチャされるなどの例外を除いて)、他のプロセスは見ることができません。
それは保護されています。
使い終えたメモリに残ったごみをどうするかはマルチタスクとは関係のない、セキュアOSとしてのポリシーの問題です。
全ての情報が漏えいしてはならないわけはなく、(特に低スペックなマシンの場合)すべてのVRAMをクリアするべきかどうかは別の問題となります。