アカウント名:
パスワード:
Purifyを使えといったのではなく、Purifyのようにセグメントを管理し、領域を越えた時点で検知するユーザレベルで動くライブラリのアプローチを取るものを使えば良いといったのです。このアプローチで最もよく知られているのはPurifyなので、具体例としてPurifyの名前を出したまでです。このアプローチでの研究はいくつもあり(日本でもあります)、使えそうなものもいつくかあります。 もちろん何もしないよりパフォーマンスは落ちますが、少なくともOpenBSDのような一々システムコールを呼ぶというような、パフォーマンスの悪い方式よりはまだマシです。 セキュリティ云々の問題と、筋の悪い解決方法をチョイスすることとは全然別な話ですよ。
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.
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 らしいよ。
高速でかつセキュリティなものも出来るのですが。 あなたの文章を読んで無知が一番強いという言葉を思い出しました。
「セキュアなもの」ね。 無知が一番強いというのは、確かなようだ。 (フレームのもと)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
これはつまり (スコア:1)
Re:これはつまり (スコア:2, 参考になる)
Re:これはつまり (スコア:2, すばらしい洞察)
ええと、malloc(3)はシステム「ライブラリ」のtypoですよね?
たしか、OpenBSDは安全性をウリにしているOSだと思うので、パフォーマンスを犠牲にして安全性を保障するというのは一つの戦略として僕はわからんでもないです。システムライブラリのmallocを置き換えてしまえば、mallocを使用している多くのプログラムの安全性を一挙に高めることが出来ますからね。
Pur
Re:これはつまり (スコア:0)
Purifyを使えといったのではなく、Purifyのようにセグメントを管理し、領域を越えた時点で検知するユーザレベルで動くライブラリのアプローチを取るものを使えば良いといったのです。このアプローチで最もよく知られているのはPurifyなので、具体例としてPurifyの名前を出したまでです。このアプローチでの研究はいくつもあり(日本でもあります)、使えそうなものもいつくかあります。 もちろん何もしないよりパフォーマンスは落ちますが、少なくともOpenBSDのような一々システムコールを呼ぶというような、パフォーマンスの悪い方式よりはまだマシです。 セキュリティ云々の問題と、筋の悪い解決方法をチョイスすることとは全然別な話ですよ。
Re:これはつまり (スコア:2, 参考になる)
はずれ。
と書いてある。malloc(3) が毎回 mmap(2) を呼ぶのではなく、今まで brk(2) を読んでいた箇所で mmap(2) を使うようにしただけ。free(3) がカーネルにメモリを返すのも当然毎回ではなくそのページ中に割り当てられたチャンクがすべて free(3) された時。元記事のリンク先に
毎回 mmap(3) を呼んで新たにページを割り当ててたら、システムコールのオーバーヘッド云々以前に、数バイト、数十バイト単位のチャンクを大量に malloc(3) するプログラムがメモリを食い尽くしてしまう。テストどころの騒ぎではない。火を見るより明らか。そんなことはしないでしょ。
となると、この変更の効果は実用環境でのオーバーラン等の被害を減らし、またバグを検出しやすくすることではあるけど、徹底的にバグをたたき出すものではない。Purify のようなものとは用途がずれている。
Re:これはつまり (スコア:1, 興味深い)
mmap や brk で大きめの領域を確保しおいて malloc がその領域から割り当てを行うことも、free した領域に関する扱いも処理系依存で実装により違うのでは?
というのは置いておいて、OpenBSD 3.4 Release [openbsd.org] で、
と明らかに高速性よりも積極的なセキュリティを重視する戦略を取っているので、パフォーマンスは無視してでも潜在的に問題がありそうなところは徹底して潰すほうが OpenBSD らしいよ。
Re:これはつまり (スコア:0)
高速でかつセキュリティなものも出来るのですが。 あなたの文章を読んで無知が一番強いという言葉を思い出しました。
Re:これはつまり (スコア:1)
「セキュアなもの」ね。 無知が一番強いというのは、確かなようだ。 (フレームのもと)
Re:これはつまり (スコア:1)
つまり、#788069では、ユーザランドのライブラリ じゃなくてシステムコールで解決しようとしているのが馬鹿なこととおっしゃってたのですね。システムライブラリに組み込むのが馬鹿なことなのではなく、そのアルゴリズムに関する異議なのですよね?それなら合点です。すいません。
ところで、ユーザランドでのmalloc置き換えの実装と言うと、例えば以下のものもそうなのではないかと想像しますが、これらと比べても今回のOpenBSDのアプローチはhigh costですかね? 昔、これらに類するツールをいくつかちょこっと試してみた感想なのですが、それらも通常のmallocを使った場合と比べて大分パフォーマンスが悪かった記憶がありますので、それ以上遅いと実用には向かない気がいたします。その時、私の使ったツールのアルゴリズムがたまたま悪かったのでしょうか? この種のツールのみなさんの比較経験を教えて頂けるとありがたいです。
# って、もうこの記事にはコメントつかなそうですが...