malloc(3)で確保したメモリは初期化されないよ
> The malloc() function allocates size bytes and returns a pointer to the allocated memory. The memory is not initialized.
(man malloc)
@zundan はい。私の記憶が正しければ、Linuxだとプロセスを作ったときに情報が漏れないように、プロセスが初期化する範囲内だとmallocでもokだったはず。
でも書いてて、プロセスが初期化する範囲についてわかってないことに気がついた。
なるほど、他人に反応してみると良いことある。
@yabuki なるほどLinuxプロセス!! 実装依存で初期化されている可能性はありますねー。
僕の参照していたのはUbuntu 22.04のmanページで、POSIX.1-2001, POSIX.1-2008, C89, C99に準拠しているそうで、この範囲では初期化されていない可能性も考えて実装する必要がありそうです。
@zundan はい。callocを使うか、memsetで必要な部分毎に初期化するとかしますね。
読み出しより、書き込みが先に確定しているなら、クロック数を稼ぐのにmallocのままもあるかなあ。バグの元なので初期化は王道ですけど。
私の記憶が確かなら、前のプロセスの情報が悪用されないため。でセキュリティ対策だったので、コンパイラーが勝手に判断して最適化する話ではないと思っております。
@yabuki お返事ありがとうございます！
なるほど、セキュリティが理由なんですね。前の情報を残さない、というのはとても納得できました。
しかしその場合、環境変数とかsetarch(8)とかの影響で変わらないかは心配ですね。
> しかしその場合、環境変数とかsetarch(8)とかの影響で変わらないかは心配ですね。
ごめんなさい。何を心配しているのか私には理解できないので、どういう機序というか仕組みで、心配なのか教えていただけませんか。
プロセスが破棄されると環境変数も破棄されると理解していたものですから。何かご存知だから発言されているのでしょうし。
@yabuki なんか言葉足らずでしたね、すみません。まずは破棄（環境変数の中身が残る心配）については自分もそう思います。
環境変数と書いたのは、「実行時の設定一つで、プロセス中のmallocの動作に影響を及ぼせますよね」という意味でした。たとえばMALLOC_CHECK_とかです。
https://manpages.debian.org/bullseye/manpages-dev/mallopt.3.en.html#MALLOC_CHECK_
それと、setarch -Rも同様に思えました。ASLRというやつ（の無効化）だと思います。
https://manpages.debian.org/bullseye/util-linux/setarch.8.en.html#R
それで、こういう関係がゼロクリアに影響をしないのだろうか、というのが、心配と書いた部分です。
（ただ「心配」という曖昧な表現の通り、自分にはあまり確たる知識はなく、たまたま思い浮かべた……というところです）
malloc_check と ASLR は、コンピュータを守るという目的はいっしょですが、使う目的が異なるので、べつの用途だという認識です。
malloc_checkは、プログラムがメモリをぶっ壊した時に検出するためのもの。
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c904.html
@tadd DebianにおけるASLRについては、こちらをご確認ください。
@yabuki すみません、うまく通じてなかったです。
はい、それらの用途が同じ・違う、とは思っていなかったです。
・実行時の設定一つで、プロセス中のmallocの動作に影響を及ぼせるので
・こういう関係がゼロクリアに影響をしないのだろうか
で、つまりは「他のあらゆる動的な設定は一切影響しないのだろうか？」という疑問でした。
glibcにおけるcallocのコードを追っかけて話をするべきですが、callocは、mallocしたのちにメモリクリアをするように書かれていると思います。
@yabuki いえいえ、コードまでは大丈夫です。（むしろ手を煩わせて申し訳ないです）
自分も気になったら調べてみようと思います。
ただまず調べるなら、malloc処理を内蔵してる側のgcc/clangの方がいい気がしています。
printfと同じく、静的解析+最適化の結果で、glibc本体の呼び出し方が変わったり消えたりする、は十分あり得ると推理しています。
@tadd 前提条件として、メモリ管理はOSの仕事であり、system callを呼び出す処理をglibcでやっていますよね。
そこと、どのような整合で、そうなるのか具体例で教えていただけませんか?
@yabuki そこはほんと、おっしゃるとおりと思います。ただgccが組み込み関数として処理を持っていますね、というだけのお話でした。
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Other-Builtins.html#index-malloc
@tadd えっと、mallocとallocを同一視していらっしゃる?
実行しているプロセスのスタック領域からメモリーを引っ張ってくるallocと、system callを呼んで、メモリを引っ張ってくるmallocは、違うものですよ。
@yabuki あれ、ごめんなさい。まずはallocaでしょうか。そっちについては特に書いていないつもりです。
@tadd なるほど。
> The ISO C90 functions abort, abs, acos, asin, atan2, atan, calloc, ceil, cosh, cos, exit, exp, fabs, floor, fmod, fprintf, fputs, free, frexp, fscanf, isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper, labs, ldexp, log10, log, malloc, memchr, memcmp, memcpy, memset, modf, pow,
> printf, putchar, puts, realloc, scanf, sinh, sin, snprintf, sprintf, sqrt, sscanf, strcat, strchr, strcmp, strcpy, strcspn, strlen, strncat, strncmp, strncpy, strpbrk, strrchr, strspn, strstr, tanh, tan, vfprintf, vprintf and vsprintf are all recognized as built-in functions unless -fno-builtin is specified (or -fno-builtin-function is specified for an individual function). All of these functions have corresponding versions prefixed with __builtin_.
@tadd の部分の話をされていらっしゃると。
@tadd ビルドオプションを確認しないとなんともわからないです。
@yabuki ですね、そこもおっしゃるとおりだと思います。-fno-builtinで挙動が変わって困る、という記事は、mallocもそれ以外もたくさん出てきます。
だとすると、（先程の動的な設定とは更に別に）コンパイラのオプションによってもやはりmallocの挙動が変わるので、glibc実装としては期待できる振る舞い（自分はそのあたりはほんと分かってないです、すみません……）にもなかなか頼れず、もし頼るならコンパイル時のfno-builtinが必須のソースになるのだろうか、と考えていました。
@yabuki といろいろ書きましたが、最適化オプション等について前提できることがあるのでしたら、自分が単に流れを落としているだけだと思います、すみません。