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，已经给我造成成吨的伤害了。。。

调试发现：

 Breakpoint 5, sshkey_private_rsa1_to_blob (key=0x556955a610,
     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
     comment=0x7fffffc758 "root@trait") at sshkey.c:3474
 3474    sshkey.c: No such file or directory.
 (gdb) p cp
 $10 = (u_char *) 0x556955aaa0 ">*"
 (gdb) n
 3482    in sshkey.c
 (gdb) p cp
 $11 = (u_char *) 0x556955aaa0 ">*>*"
 (gdb) n
 3483    in sshkey.c
 (gdb) n
 3482    in sshkey.c
 (gdb) n
 3484    in sshkey.c
 (gdb) n
 3483    in sshkey.c
 (gdb) n
 3485    in sshkey.c
 (gdb) n
 3484    in sshkey.c
 (gdb) n

 Breakpoint 6, sshkey_private_rsa1_to_blob (key=0x556955a610,
     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
     comment=0x7fffffc758 "trait@trait") at sshkey.c:3489
 3489    in sshkey.c
 (gdb) p cp
 $12 = (u_char *) 0x556955aaa0 ""
 (gdb) p buf
 $13 = "\000\000\000UiU\255`"
 (gdb) n
 3490    in sshkey.c
 (gdb) p buf
 $14 = "\000\000\000\000\000\000\000"
 (gdb) p cp
 $15 = (u_char *) 0x556955aaa0 ""
 (gdb) bt
 #0  sshkey_private_rsa1_to_blob (key=0x556955a610, blob=0x556955ad60,
     passphrase=0x556955ac20 "123456", comment=0x7fffffc758 "trait@trait")
     at sshkey.c:3490
 #1  0x00000055694fef48 in sshkey_private_to_fileblob (key=0x556955a610,
     blob=0x556955ad60, passphrase=0x556955ac20 "123456",
     comment=<optimized out>, force_new_format=<optimized out>,
     new_format_cipher=<optimized out>, new_format_rounds=<optimized out>)
     at sshkey.c:3610
 #2  0x0000005569505024 in sshkey_save_private (key=0x556955a610,
     filename=0x5569553168 <identity_file> "testpass1",
     passphrase=0x556955ac20 "123456", comment=0x7fffffc758 "trait@trait",
     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0)
     at authfile.c:85
 #3  0x00000055694f6f30 in main (argc=<optimized out>, argv=0x3d4)
     at ssh-keygen.c:2672

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

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

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

 Breakpoint 1, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
     at sshkey.c:3449
 3449    {
 (gdb) b sshkey.c:3490
 Breakpoint 2 at 0x11dbea: file sshkey.c, line 3490.
 (gdb) c
 Continuing.

 Breakpoint 2, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
     at sshkey.c:3490
 3490            if ((r = sshbuf_put(buffer, buf, 8 - (sshbuf_len(buffer) % 8))) != 0)
 (gdb) p cp
 $1 = (u_char *) 0x17eb28 "\310\065\327\267\310\065\327\267 \353\027"
 (gdb) bt
 #0  sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait") at sshkey.c:3490
 #1  0x001244a5 in sshkey_private_to_fileblob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait",
     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0) at sshkey.c:3610
 #2  0x0012d250 in sshkey_save_private (key=0x17c658, filename=0x17a0e0 "testpass", passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait",
     force_new_format=0, new_format_cipher=0x0, new_format_rounds=0) at authfile.c:85
 #3  0x0011be51 in main (argc=1398664, argv=0xbffff618) at ssh-keygen.c:2672

 Breakpoint 1, sshkey_private_rsa1_to_blob (key=0x17c658, blob=0x17eaf8, passphrase=0x17ee20 "123456", comment=0xbffff139 "trait@trait")
     at sshkey.c:3449
 3449    {
 (gdb) b sshbuf.c:350
 Breakpoint 3 at 0x11c9e5: file sshbuf.c, line 350.
 (gdb) c
 Continuing.

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

继续调试arm64的版本：

 Breakpoint 9, sshbuf_reserve (buf=0x5584d5c2e0, len=258, dpp=0x7fffffba60)
     at sshbuf.c:347
 347     in sshbuf.c
 (gdb) p (u_char *) 0x5584d5baa0
 $36 = (u_char *) 0x5584d5baa0 "\322\316\322\316"
 (gdb) n
 348     in sshbuf.c
 (gdb) n
 350     in sshbuf.c
 (gdb) p (u_char *) 0x5584d5baa0
 $37 = (u_char *) 0x5584d5baa0 "\322\316\322\316"
 (gdb) n
 356     in sshbuf.c
 (gdb) p (u_char *) 0x5584d5baa0
 $38 = (u_char *) 0x5584d5baa0 ""
 (gdb) p rlen
 $39 = 512
 (gdb) p buf->d
 $40 = (u_char *) 0x5584d5baa0 ""
 (gdb) p dp
 $41 = (u_char *) 0x5584d5cf70 "\322\316\322\316"

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

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

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