realloc在aarch64_be-gcc的奇怪表现

最近遇到一个使用aarch64_be-gcc编译的ssh服务器出现不能通过ssh1协议使用密钥+passphrase不能正常登陆的问题。

(⊙o⊙)…不要奇怪为啥还在用SSH1，我也在奇怪。。

一顿捣鼓（重现问题），发现是64位的ssh-keygen生成的密钥的不能使用设置passphrase解密，于是问题就好办了，用x86_64的ssh-keygen生成一个密钥使用，ok，正常登陆了。

那么问题就结束了嘛，当然没有，怎么也得看一下为啥arm64的ssh-keygen就不正常了。

于是编译一个debug版本，去掉-O3优化，aarch64_be-gcc的-O3优化相当crazy，已经给我造成成吨的伤害了。。。

调试发现：

 1 Breakpoint 5, sshkey_private_rsa1_to_blob (key=0x556955a610,
 2     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
 3     comment=0x7fffffc758 "root@trait") at sshkey.c:3474
 4 3474    sshkey.c: No such file or directory.
 5 (gdb) p cp
 6 $10 = (u_char *) 0x556955aaa0 ">*"
 7 (gdb) n
 8 3482    in sshkey.c
 9 (gdb) p cp
10 $11 = (u_char *) 0x556955aaa0 ">*>*"
11 (gdb) n
12 3483    in sshkey.c
13 (gdb) n
14 3482    in sshkey.c
15 (gdb) n
16 3484    in sshkey.c
17 (gdb) n
18 3483    in sshkey.c
19 (gdb) n
20 3485    in sshkey.c
21 (gdb) n
22 3484    in sshkey.c
23 (gdb) n
24 
25 Breakpoint 6, sshkey_private_rsa1_to_blob (key=0x556955a610,
26     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
27     comment=0x7fffffc758 "trait@trait") at sshkey.c:3489
28 3489    in sshkey.c
29 (gdb) p cp
30 $12 = (u_char *) 0x556955aaa0 ""
31 (gdb) p buf
32 $13 = "000000UiU255`"
33 (gdb) n
34 3490    in sshkey.c
35 (gdb) p buf
36 $14 = "00000000000000"
37 (gdb) p cp
38 $15 = (u_char *) 0x556955aaa0 ""
39 (gdb) bt
40 #0  sshkey_private_rsa1_to_blob (key=0x556955a610, blob=0x556955ad60,
41     passphrase=0x556955ac20 "123456", comment=0x7fffffc758 "trait@trait")
42     at sshkey.c:3490
43 #1  0x00000055694fef48 in sshkey_private_to_fileblob (key=0x556955a610,
44     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
45     comment=<optimized out>, force_new_format=<optimized out>,
46     new_format_cipher=<optimized out>, new_format_rounds=<optimized out>)
47     at sshkey.c:3610
48 #2  0x0000005569505024 in sshkey_save_private (key=0x556955a610,
49     filename=0x5569553168 <identity_file> "testpass1",
50     passphrase=0x556955ac20 "123456", comment=0x7fffffc758 "trait@trait",
51     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0)
52     at authfile.c:85
53 #3  0x00000055694f6f30 in main (argc=<optimized out>, argv=0x3d4)
54     at ssh-keygen.c:2672

发现cp这个变量变成空字符串了，这里openssh的代码我就不分析了，因为我也没这么读，完全是因为这个三不管的ssh服务出问题了。

这么就变成空的了呢。。。

在X86的虚拟机上面也调试了一下：

 1 Breakpoint 1, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
 2     at sshkey.c:3449
 3 3449    {
 4 (gdb) b sshkey.c:3490
 5 Breakpoint 2 at 0x11dbea: file sshkey.c, line 3490.
 6 (gdb) c
 7 Continuing.
 8 
 9 Breakpoint 2, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
10     at sshkey.c:3490
11 3490            if ((r = sshbuf_put(buffer, buf, 8 - (sshbuf_len(buffer) % 8))) != 0)
12 (gdb) p cp
13 $1 = (u_char *) 0x17eb28 "3106532726731065327267 35327"
14 (gdb) bt
15 #0  sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait") at sshkey.c:3490
16 #1  0x001244a5 in sshkey_private_to_fileblob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait",
17     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0) at sshkey.c:3610
18 #2  0x0012d250 in sshkey_save_private (key=0x17c658, filename=0x17a0e0 "testpass", passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait",
19     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0) at authfile.c:85
20 #3  0x0011be51 in main (argc=1398664, argv=0xbffff618) at ssh-keygen.c:2672
21 
22 Breakpoint 1, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
23     at sshkey.c:3449
24 3449    {
25 (gdb) b sshbuf.c:350
26 Breakpoint 3 at 0x11c9e5: file sshbuf.c, line 350.
27 (gdb) c
28 Continuing.

同样的代码，不同的结果，好吧

继续调试arm64的版本：

 1 Breakpoint 9, sshbuf_reserve (buf=0x5584d5c2e0, len=258, dpp=0x7fffffba60)
 2     at sshbuf.c:347
 3 347     in sshbuf.c
 4 (gdb) p (u_char *) 0x5584d5baa0
 5 $36 = (u_char *) 0x5584d5baa0 "322316322316"
 6 (gdb) n
 7 348     in sshbuf.c
 8 (gdb) n
 9 350     in sshbuf.c
10 (gdb) p (u_char *) 0x5584d5baa0
11 $37 = (u_char *) 0x5584d5baa0 "322316322316"
12 (gdb) n
13 356     in sshbuf.c
14 (gdb) p (u_char *) 0x5584d5baa0
15 $38 = (u_char *) 0x5584d5baa0 ""
16 (gdb) p rlen
17 $39 = 512
18 (gdb) p buf->d
19 $40 = (u_char *) 0x5584d5baa0 ""
20 (gdb) p dp
21 $41 = (u_char *) 0x5584d5cf70 "322316322316"

上面的cp指针与buf->d是同一个地址。openssh6.9p1 代码如下：

1 if ((dp = realloc(buf->d, rlen)) == NULL) {
2             SSHBUF_DBG(("realloc fail"));
3             if (dpp != NULL)
4                 *dpp = NULL;
5             return SSH_ERR_ALLOC_FAIL;
6         }

发现buf->d拷贝给了dp，但是自己内容被清空了，于是查看realloc的说明，只有一种情况貌似符合这种情况，就是buf->d指向的内存区域被移动了，这会是谁干的？realloc？？？