アカウント名:
パスワード:
64bitアドレスになればoverflowするほどメモリは積めないので大丈夫!
# ウソ度1000%なのでID
ちょっとマジレスですが, いくら20年前の人でも32bitじゃあすぐに足りなくなるのは見えていましたよ. その時点で例えば画像処理や数値計算用途では20bit(i8086, Z8000)では全く役立たず, 24bit(mc68000, ns32016)でなんとかという状態でしたから. 余裕は8bit分, 容量で256倍になれば終わりです.
今回の32bitアドレスから64bitアドレスへの変更はbit数で見れば2倍になったにすぎませんが, 容量で見れば40億倍. ムーアの法則の様な対数的容量増加が続いたと仮定しても, 32bitCPUが主流になってから今までの時間の3~4倍はもつ計算になります.
ただ今度は富豪的メモリ空間割り当て手法とかを使って, 実メモリとは関係無しにアドレスを食いつぶすなんてこともあり得ますけどね.
メモリは手元にあるとは限らないし、アドレスはメモリ上のデータを指すとも限らないですからね。
ネットワーク上の他ノードのメモリ空間や、ファイル等のリソースを全てメモリ空間にマップするって話も新しいものじゃないし。 (10年以上前ですが、当時は64bitあれば何とかなるんじゃないって話だったかな)。
あれ? Linux はかなり昔から /bin /sbin ともにダイナミックリンクだったはずですよ。覚えているのは slackware 3.1 の頃からですが。 # むしろこの事で、 *BSD 使いの人に「キモい」と言われていました(笑)
以下 debian sid の結果。 2 つとも意図的にスタティックリンクしたものですね % file /{bin,sbin}/* | grep statically /bin/sash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped /sbin/ldconfig: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
訂正です。
Fedora で確かめてみたら、 filesystem 周りのコマンドも statically linked でした。 distribution に依るんですね。
# splint とかにこの手のチェックを盛り込めないかな...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
integer overflow (スコア:0)
ヤバそうな所を自動検出するツールとか作れないかな。
Re:integer overflow (スコア:2, おもしろおかしい)
64bitアドレスになればoverflowするほどメモリは積めないので大丈夫!
# ウソ度1000%なのでID
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:1)
ちょっとマジレスですが, いくら20年前の人でも32bitじゃあすぐに足りなくなるのは見えていましたよ. その時点で例えば画像処理や数値計算用途では20bit(i8086, Z8000)では全く役立たず, 24bit(mc68000, ns32016)でなんとかという状態でしたから. 余裕は8bit分, 容量で256倍になれば終わりです.
今回の32bitアドレスから64bitアドレスへの変更はbit数で見れば2倍になったにすぎませんが, 容量で見れば40億倍. ムーアの法則の様な対数的容量増加が続いたと仮定しても, 32bitCPUが主流になってから今までの時間の3~4倍はもつ計算になります.
ただ今度は富豪的メモリ空間割り当て手法とかを使って, 実メモリとは関係無しにアドレスを食いつぶすなんてこともあり得ますけどね.
Re:integer overflow (スコア:0)
メモリは手元にあるとは限らないし、アドレスはメモリ上のデータを指すとも限らないですからね。
ネットワーク上の他ノードのメモリ空間や、ファイル等のリソースを全てメモリ空間にマップするって話も新しいものじゃないし。 (10年以上前ですが、当時は64bitあれば何とかなるんじゃないって話だったかな)。
Re:integer overflow (スコア:1)
libsafe [avayalabs.com]とかがお勧めです。自動検出ツールは
知らないですけど。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
libsafe(off topic) (スコア:2, 参考になる)
ちなみにlibcをstaticリンクしている
バイナリにlibsafeは効きません。
BSDは先日 /binをdynamicリンクしました [srad.jp]が、
Linuxはふつうはしていないのでスタティックリンクしている
/bin /sbin に関数のバグには注意....
あ、libparanoiaもあったか。あれってどうなってるのかな...
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:libsafe(off topic) (スコア:3, 参考になる)
あれ? Linux はかなり昔から /bin /sbin ともにダイナミックリンクだったはずですよ。覚えているのは slackware 3.1 の頃からですが。
# むしろこの事で、 *BSD 使いの人に「キモい」と言われていました(笑)
以下 debian sid の結果。 2 つとも意図的にスタティックリンクしたものですね
% file /{bin,sbin}/* | grep statically
/bin/sash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
/sbin/ldconfig: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
Re:libsafe(off topic) (スコア:2, 参考になる)
訂正です。
Fedora で確かめてみたら、 filesystem 周りのコマンドも statically linked でした。
distribution に依るんですね。
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:2, 参考になる)
防ぐことはしないけど、インテガーオーバーフローが
原因でおこるバファーオーバーフローを防ぐことが
できます。
#今回の件で言えば、カーネルのバファーオーバフローを
#防ぐ事ができます。
インテガーオーバーフローが原因の脆弱性は
多くの場合それが、バファーオーバーフローを
起こさせててコードを走らせているように思うので、
結果的には多くのインテガーオーバーフローが原因の
脆弱性にも有効な対策のように私は思います。
SafeintはC++ソースがあって、自分でコンパイルして
走らせる場合には大変良いと思います。
#Pingをピングと書く人間なので読みにくかったら
#ゴメソ
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:integer overflow [補足] (スコア:1)
だめらしいです。ちなみに、私はカーネルが
Cでかかれているのかさえ知らないダメポなので、
今回の脆弱性をlibsafeで防げるのか知りません。
カーネルなんだから、リンクとかは利用しないような
気がするので、libsafeがlibcをダイナミックで
利用してるプログラム用だとカーネルの
バッファオーバーフローは防げないですね。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:1)
# splint とかにこの手のチェックを盛り込めないかな...