c - malloc が本当に非決定論的であるのはなぜですか? (Linux/Unix)

Question

mallocが 0 のメモリを返すことは保証されていません。従来の知恵は、それだけでなく、メモリmallocの戻り値の内容は実際には非決定論的であるということです。たとえば、openssl は追加のランダム性のためにそれらを使用していました。

ただし、私の知る限り、mallocはbrk/sbrkの上に構築されており、これは 0 のメモリを「返す」ものです。mallocが返す内容が、たとえば以前に解放されたメモリから0 以外である理由はわかりますが、「通常の」シングルスレッドソフトウェアではなぜそれらが非決定論的でしょうか?

従来の知恵は本当に真実ですか (同じバイナリとライブラリを想定)
もしそうなら、なぜですか？

編集上記の質問ですでに説明したように、メモリが0以外になる理由を説明する人が何人かいます。私が求めているのは、malloc が返す内容を使用するプログラムが非決定論的である可能性がある理由、つまり、実行するたびに異なる動作をする可能性がある理由です (同じバイナリとライブラリを想定して)。非決定的な動作は、非 0 によって暗示されません。別の言い方をすれば、バイナリが実行されるたびに異なる内容になる理由です。

score 11 · Accepted Answer

Mallocは予測不可能性を保証しません...それは予測可能性を保証するものではありません。

例：

 return 0;

mallocの有効な実装です。

score 4 · Accepted Answer

によって返されるメモリの初期値mallocは指定されていません。つまり、C および C++ 言語の仕様では、返される値に制限がありません。これにより、さまざまなプラットフォームでの言語の実装が容易になります。mallocLinux ではとで実装されているのは事実かもしれませんがbrk、sbrkメモリをゼロにする必要があります (ちなみに、これが必ずしも正しいかどうかはわかりません)。他のプラットフォーム、おそらく組み込みプラットフォームでは、そうしなければならない理由はありません。たとえば、組み込みデバイスはメモリをゼロにしたくない場合があります。そうすると、CPU サイクルが消費され、電力と時間がかかるためです。また、たとえば、効率を高めるために、メモリアロケータは、以前に解放されたブロックを最初にゼロに設定せずにリサイクルすることができます。これは、OS からのメモリが最初にゼロになったとしても、OS からのメモリはゼロにするmalloc必要がないことを意味します。

値が非決定的であるという従来の通念はおそらく良いものです。なぜなら、返されたメモリには、プログラムをクラッシュさせる可能性のあるガベージデータが含まれている可能性があることを認識する必要があるからです。とはいえ、値が真にランダムであると想定すべきではありません。ただし、返される値が魔法のように望むものになるわけではないことに注意してください。それらを正しく設定する責任があります。値が本当にランダムであると仮定することは、本当に悪い考えです。

ゼロ化されることが保証されているメモリが必要な場合は、calloc代わりに使用してください。

お役に立てれば！

score 3 · Accepted Answer

mallocは、C/C++ でプログラミングできる多くのシステムで定義されています。これには、多くの非 UNIX システムや、オペレーティングシステムがまったくない多くのシステムが含まれます。メモリをゼロにすることを要求mallocすることは、CPU を可能な限り節約するという C の哲学に反します。

標準ではcalloc、メモリをゼロにする必要がある場合に使用できるゼロ調整機能が提供されています。ただし、メモリを取得したらすぐに自分でメモリを初期化することを計画している場合、ブロックがゼロに設定されていることを確認するために費やされる CPU サイクルは無駄になります。C 標準は、多くの場合、予測可能性を犠牲にして、この無駄を可能な限り回避することを目的としています。

score 3 · Accepted Answer

によって返されるメモリは、ゼロにする必要がないため、ゼロにはなりmallocません (ゼロになる保証はありません)。独自のプロセスのアドレス空間またはページプールから引き出された初期化されていないメモリを再利用しても、セキュリティ上のリスクはありません。あなたはそれがそこにあることをすでに知っており、あなたはすでにその内容を知っています。内容も上書きするので実用上は問題ありません。

ちなみに、によって返されるメモリは、malloc 最初の割り当て時にゼロになります。これは、オペレーティングシステムカーネルが、別のプロセスが以前に所有していた 1 つのプロセスデータを与えるリスクを許容できないためです。したがって、OS が新しいページで障害を起こすと、ゼロになったページだけが提供されます。ただし、これはとはまったく関係ありませんmalloc。

(少し話題から外れています: あなたが言及した Debian のセキュリティの問題には、ランダム性のために初期化されていないメモリを使用するよりもいくつかの意味がありました。コードの内部動作に精通しておらず、正確な意味を知らなかったパッケージャーが、いくつかの場所にパッチを当てました。 Valgrind が報告したことは、おそらく善意であったが、壊滅的な結果をもたらした. これらの中には、「初期化されていないメモリからのランダム」があったが、最も深刻なものではなかった.)

score 2 · Accepted Answer

特に非スレッドコンテキストを要求する場合、それが非決定論的であるという仮定は明らかに間違っていると思います。（スケジュールアレアによるスレッド化されたコンテキストでは、非決定論が発生する可能性があります）。

試してみてください。シーケンシャルで決定論的なアプリケーションを作成します。

たくさんの割り当てを行います
メモリを何らかのパターンで埋めます。たとえば、カウンタの値で埋めます。
これらの割り当てを毎秒解放します
同じ金額を新たに割り当てる
これらの新しい割り当てを実行し、ファイルの最初のバイトの値を登録します（1行に1つのテキスト番号として）

このプログラムを2回実行し、結果を2つの異なるファイルに登録します。私の考えは、これらのファイルは同一になるということです。

score 1 · Accepted Answer

「通常の」シングルスレッドプログラムでも、メモリは何度も解放され、再割り当てされます。Mallocは、以前に使用した記憶を返します。

score 1 · Accepted Answer

シングルスレッドコードでさえ、mallocを実行してから解放し、次にmallocを実行して、以前に使用されていたゼロ以外のメモリを取り戻すことができます。

score 1 · Accepted Answer

brk/sbrkが 0ed-out データを返すという保証はありません。これは実装の詳細です。一般に、あるプロセスからの機密情報が別のプロセスに渡される可能性を減らすために、OS がこれを行うことは良い考えですが、仕様には、そうなるとは書かれていません。

また、 /mallocの上に実装されるという事実も実装に依存し、割り当てのサイズに基づいて変化することさえあります。たとえば、Linux での大規模な割り当ては、従来は代わりに /dev/zero を使用していました。brksbrkmmap

malloc()基本的に、ガベージを含む ed 領域や、それがすべて 0 であることに依存することはできません。

score 0 · Accepted Answer

答えを出す最も簡単な方法は次のとおりです。

壁画を描くための壁スペースを探している場合、下塗りして上からペイントするので、白か古い落書きで覆われているかは気にしません。私が気にするのは、写真を収めるのに十分な面積があるかどうかだけであり、他の誰かに属する領域の上に絵を描いていないことだけを気にします.

それがmallocの考え方です。プロセスが終了するたびにメモリをゼロにすると、計算上の労力が無駄になります。塗装が終わるたびに壁を塗り直すようなものです。

score -1 · Accepted Answer

コンピュータメモリ内に存在するプログラムのエコシステム全体があり、mallocとfreeが発生する順序を制御することはできません。

アプリケーションとmalloc（）を初めて実行するときに、ごみのあるアドレスが提供されると想像してみてください。次に、プログラムがシャットダウンし、OSがその領域を空きとしてマークします。別のプログラムは別のmalloc（）でそれを受け取り、多くのものを書き込んでから終了します。プログラムを再度実行すると、malloc（）が同じアドレスを提供する場合がありますが、前のプログラムが書き込んだ可能性のある別のガベージがあります。

私は実際にどのシステムでもmalloc（）の実装を知りませんし、それが何らかのセキュリティ対策（返されたアドレスのランダム化など）を実装するかどうかもわかりませんが、そうは思いません。

それは非常に決定論的です。

c - malloc が本当に非決定論的であるのはなぜですか? (Linux/Unix)

10 に答える 10

Related

Reference