パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

OpenBSD、malloc(3) を改良。多数パッケージに影響か」記事へのコメント

  • Linux等でも同じようにmallocを修正すれば、バグの叩き出しができるんでしょうか?
    • Re:これはつまり (スコア:2, 参考になる)

      by Anonymous Coward
      Linuxではむかしからmallocはmmapを使っています。というかbrkはPOSIX.1ではないので意図的に使っていません。それからシステムコールになんかしたらパフォーマンスがあがらないので、そんな馬鹿なことを平気でする感覚がわからないです。mallocのバグ出しには
      • Re:これはつまり (スコア:2, すばらしい洞察)

        > それからシステムコールになんかしたらパフォーマンスがあがらないので、

        ええと、malloc(3)はシステム「ライブラリ」のtypoですよね?

        たしか、OpenBSDは安全性をウリにしているOSだと思うので、パフォーマンスを犠牲にして安全性を保障するというのは一つの戦略として僕はわからんでもないです。システムライブラリのmallocを置き換えてしまえば、mallocを使用している多くのプログラムの安全性を一挙に高めることが出来ますからね。

        Pur
        • by Anonymous Coward on 2005年08月27日 11時58分 (#788635)
          たぶんあなたはmallocの中身が理解できていないので、まず、そこから始めます。mallocはまずシステムコールmmapあるいはbrkを呼びある程度のメモリ空間をプールしておきます。次に、mallocが呼ばれたときに、その中を必要に応じて刻んで渡します。freeをされると、リサイクル用リストに入ります。次にmallocが呼ばれたらfreeされているリサイクル用リストに適切なものがあれば、そちらから引渡し、なければプールされている領域から取ります。これがユーザ空間で行われるため、単純なポインタの付け替えだけで処理できます。ですから非常に高速です。ただしmallocで受け渡されたメモリとは、以前に取られたメモリ空間の一部ですから、そこにはいくらでも書き込めるわけです。オーバーランをすれば、malloc内部の管理ポインタも壊すし、他のところで使われているデータも壊します。OpenBSDは、この「システムコールで一度にある程度のサイズを取る」ということをせずに、mallocが呼ばれれば内部でシステムコールであるmmapを毎回呼びます。ですから、もしオーバーランをすると、他には何も影響せずメモリセグメントのエラーになります。そしてfreeをすれば、mmapの空間は解放されます。これはプロセスから完全にメモリを解放するという意味です。仕組みといっている意味がわかりましたか?

          Purifyを使えといったのではなく、Purifyのようにセグメントを管理し、領域を越えた時点で検知するユーザレベルで動くライブラリのアプローチを取るものを使えば良いといったのです。このアプローチで最もよく知られているのはPurifyなので、具体例としてPurifyの名前を出したまでです。このアプローチでの研究はいくつもあり(日本でもあります)、使えそうなものもいつくかあります。 もちろん何もしないよりパフォーマンスは落ちますが、少なくともOpenBSDのような一々システムコールを呼ぶというような、パフォーマンスの悪い方式よりはまだマシです。 セキュリティ云々の問題と、筋の悪い解決方法をチョイスすることとは全然別な話ですよ。

          親コメント
          • Re:これはつまり (スコア:2, 参考になる)

            by zenkakueisuuji (20374) on 2005年08月29日 10時29分 (#789452) 日記
            OpenBSDは、この「システムコールで一度にある程度のサイズを取る」ということをせずに、mallocが呼ばれれば内部でシステムコールであるmmapを毎回呼びます。

            はずれ。
            元記事のリンク先に

            - As before, objects smaller than a page are allocated within shared pages that malloc(3) maintains. But their allocation is now somewhat randomized as well.
            と書いてある。malloc(3) が毎回 mmap(2) を呼ぶのではなく、今まで brk(2) を読んでいた箇所で mmap(2) を使うようにしただけ。free(3) がカーネルにメモリを返すのも当然毎回ではなくそのページ中に割り当てられたチャンクがすべて free(3) された時。
            毎回 mmap(3) を呼んで新たにページを割り当ててたら、システムコールのオーバーヘッド云々以前に、数バイト、数十バイト単位のチャンクを大量に malloc(3) するプログラムがメモリを食い尽くしてしまう。テストどころの騒ぎではない。火を見るより明らか。そんなことはしないでしょ。
            となると、この変更の効果は実用環境でのオーバーラン等の被害を減らし、またバグを検出しやすくすることではあるけど、徹底的にバグをたたき出すものではない。Purify のようなものとは用途がずれている。

            親コメント
          • by Anonymous Coward on 2005年08月27日 16時36分 (#788725)

            mmap や brk で大きめの領域を確保しおいて malloc がその領域から割り当てを行うことも、free した領域に関する扱いも処理系依存で実装により違うのでは?


            というのは置いておいて、OpenBSD 3.4 Release [openbsd.org] で、

            カーネルおよびユーザランドのユーティリティから、多数の安全ではない文字列関数が除去されました。 これは、OpenBSD でほとんど総合的に実施されてきた監査の一環であり、何千個もの strcpy(3)、 strcat(3)、 sprintf(3) や vsprintf(3) が、より安全で制限のある strlcpy(3)、 strlcat(3)、 snprintf(3)、 vsnprintf(3)、 や asprintf(3) で代替されました。

            と明らかに高速性よりも積極的なセキュリティを重視する戦略を取っているので、パフォーマンスは無視してでも潜在的に問題がありそうなところは徹底して潰すほうが OpenBSD らしいよ。

            親コメント
            • by Anonymous Coward
              >明らかに高速性よりも積極的なセキュリティを重視する

              高速でかつセキュリティなものも出来るのですが。 あなたの文章を読んで無知が一番強いという言葉を思い出しました。

          • by tt_net (17623) on 2005年08月29日 4時31分 (#789379)
            大変有用な解説をありがとうございます。でも、ごめんなさい、それは踏まえてこの話はしているつもりでした(ところで、#788069のACさんですよね?) 。そもそも、それが分かってないと、このトピックの面白みがわかりませんし;)。

            つまり、#788069では、ユーザランドのライブラリ じゃなくてシステムコールで解決しようとしているのが馬鹿なこととおっしゃってたのですね。システムライブラリに組み込むのが馬鹿なことなのではなく、そのアルゴリズムに関する異議なのですよね?それなら合点です。すいません。

            ところで、ユーザランドでのmalloc置き換えの実装と言うと、例えば以下のものもそうなのではないかと想像しますが、これらと比べても今回のOpenBSDのアプローチはhigh costですかね? 昔、これらに類するツールをいくつかちょこっと試してみた感想なのですが、それらも通常のmallocを使った場合と比べて大分パフォーマンスが悪かった記憶がありますので、それ以上遅いと実用には向かない気がいたします。その時、私の使ったツールのアルゴリズムがたまたま悪かったのでしょうか? この種のツールのみなさんの比較経験を教えて頂けるとありがたいです。

            • ccmalloc http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/
            • Electric Fence http://perens.com/FreeSoftware/


            # って、もうこの記事にはコメントつかなそうですが...
            親コメント

アレゲは一日にしてならず -- アレゲ見習い

処理中...