2

CentOS と Debian の両方でプログラムを実行しています。出力はまったく同じですが、Centos では太字の 3 行が表示されますが、Debian では表示されません。これらの 3 行は何についてであり、どうすれば Debian でも入手できますか?

execve("./z1", ["./z1"], [/* 31 変数 */]) = 0
brk(0) = 0x8458000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (そのようなファイルまたはディレクトリはありません)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f41000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (そのようなファイルやディレクトリはありません)
open("/home/myuser/public_html/libs/libmudflap.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PJ\0\ 0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=105432, ...}) = 0
mmap2(NULL, 943136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xd89000
mmap2(0xda2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19) = 0xda2000
mmap2(0xda3000, 836640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xda3000
閉じる (3) = 0
open("/home/myuser/public_html/libs/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320m\ 1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1327556, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f40000
mmap2(NULL, 1337704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x891000
mprotect (0x9d1000、4096、PROT_NONE) = 0
mmap2 (0x9d2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x140) = 0x9d2000
mmap2(0x9d5000, 10600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9d5000
閉じる (3) = 0
open("/home/myuser/public_html/libs/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n \0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9736, ...}) = 0
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x74e000
mmap2 (0x750000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x750000
閉じる (3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f3f000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f3f6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY) = 3 
read(3, "\f\233\37", 3) = 3 
close(3) = 0
mprotect (0x750000、4096、PROT_READ) = 0
4

1 に答える 1

4

straceとは何の関係もないと思います。よくわかりませんが、メモリ内での配置と関係があるのではないでしょうか。一部のシステムは、悪意のあるアクティビティから保護するために、バイナリの一部をメモリ内のランダムな場所に配置することを知っています。これは、アドレス空間配置のランダム化（ASLR）と呼ばれます。CentOSはこれを使用しており、Debianは使用していないと思います。CentOSでのASLRの無効化については、この投稿を参照してください。それを試して、straceが/ dev/urandomが開いていることをまだ示しているかどうかを確認してください。

つまり、不一致の原因となっているのはstraceやプログラムではなく、システムである可能性があるということです。

- 編集 -

だから私は上記で間違っているかもしれません。私はこの質問についてたくさんの調査を行い、なんとかそれを絞り込むことができました。私が見つけたのは、これらの呼び出しを行っているのはライブラリである可能性が高いということです。私が使用した方法は少し複雑でしたが、実行可能でした。 それでも興味がある場合は、 この投稿を参照してください。

私が書いた単純なテストプログラムはurandomの読み取りをトリガーしなかったので、私はgnome（eog）の目を使用してこのデバッグを行いました。私の場合、Gkt +が原因であることがわかりました。乱数を使用して、一部のオブジェクトの一意のIDを作成します。私はあなたのプログラムがこれらの呼び出しを行うために何を使用しているのか知りたいです。この時点で、それがASLRであるとは思えません。

于 2011-04-30T21:06:34.117 に答える