アカウント名:
パスワード:
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, 興味深い)
理屈は分かるが...
これは、BSD Purify を作って OpenBSD と一緒に配布した方が、よりセキュアだと言ってるの?
それとも Pufity みたいなメモリチェッカーを使わないフリーソフト作者はこの世から排除すべきだと言っている?
なんというか、ぼくは OpenBSD らしい方法だと思う。とにかくセキュアにしたい、でも怪しいフリーソフトも使ってみたい、という場合もまああるにはあると思うので、こういうのがあってもいいと思う。このぐらいやらないと、OpenBSD の存在意義が無いというかなんというか。
Re:これはつまり (スコア:2, すばらしい洞察)
ええと、malloc(3)はシステム「ライブラリ」のtypoですよね?
たしか、OpenBSDは安全性をウリにしているOSだと思うので、パフォーマンスを犠牲にして安全性を保障するというのは一つの戦略として僕はわからんでもないです。システムライブラリのmallocを置き換えてしまえば、mallocを使用している多くのプログラムの安全性を一挙に高めることが出来ますからね。
Purifyなどのツールはあくまで個々のプログラムを検査・分析する為のツールのように思います。一方で今回のOpenBSDの方法はOS上で走っているプログラムを含めたシステムトータルの安全性を高める戦略で、目的が異なります。
そして、そのOpenBSDが検査にも使えるってのはあくまで2次的な用途です。こういうのをアレゲっていうんでしょ?(笑) ちがうかな。
Re:これはつまり (スコア:0)
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を使った場合と比べて大分パフォーマンスが悪かった記憶がありますので、それ以上遅いと実用には向かない気がいたします。その時、私の使ったツールのアルゴリズムがたまたま悪かったのでしょうか? この種のツールのみなさんの比較経験を教えて頂けるとありがたいです。
# って、もうこの記事にはコメントつかなそうですが...
Re:これはつまり (スコア:1, すばらしい洞察)
これはOpenBSD だぜ。
いいじゃねぇか、実用OS を使った壮大な実験なんだよ、これは。
Re: これはつまり (スコア:1)
ふむ。
> というかbrkはPOSIX.1ではないので意図的に使っていません。
standard至上主義はよしとして、
> それからシステムコールになんかしたらパフォーマンスがあがらないので、
何をシステムコールにしたら性能が上がらないのでしょうか?
malloc(3)をmmap(2)だろうがsbrk(2)だろうが、どっちにしろシステムコールを呼ぶ場合がある
という状況に変わりはないと思うのですが。