[PATCH] sha3sum: New applet, v2
Baruch Siach
baruch at tkos.co.il
Sun Jan 6 15:57:59 UTC 2013
Hi Lauri,
On Sun, Jan 06, 2013 at 05:39:11PM +0200, Lauri Kasanen wrote:
> > > > Well, as mentioned, I don't have such a system. Could you do a debug
> > > > build (CONFIG_DEBUG=y) and get valgrind output?
> > > >
> > > > echo test | valgrind ./busybox_unstripped sha3sum
> > >
> > > Unfortunately, valgrind does not support this PowerPC variant (e500v2). I'll
> > > try gdb and see what I get.
> >
> > Here it is:
> >
> > (gdb) target remote 192.168.26.170:1234
> > Remote debugging using 192.168.26.170:1234
> > 0x10001f9c in _start ()
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > KeccakF (state=0xbf8d1f30, in=<value optimized out>, laneCount=8)
> > at libbb/hash_md5_sha.c:977
> > 977 state[laneCount] ^= SWAP_LE64(in[laneCount]);
> > (gdb) bt
> > #0 KeccakF (state=0xbf8d1f30, in=<value optimized out>, laneCount=8)
> > at libbb/hash_md5_sha.c:977
> > #1 0x10051474 in sha3_hash (state=0xbf8d1f30, data=0x10172fd0 "",
> > bytes=<value optimized out>) at libbb/hash_md5_sha.c:1055
> > #2 0x1003b544 in hash_file (filename=<value optimized out>)
> > at coreutils/md5_sha1_sum.c:151
> > #3 0x1003b7c4 in md5_sha1_sum_main (argc=<value optimized out>,
> > argv=<value optimized out>) at coreutils/md5_sha1_sum.c:247
>
> Both state[8] and in[8] have to be valid at that point, there's no way
> from the code for them to have less size than 200 and 72 respectively.
>
> So it looks to me that the swap_le64 itself is crashing, but I'm not
> sure about that, it should be a GCC builtin. Alternatively, does your
> platform crash from unaligned access? State is 32-bit aligned currently,
> not 64.
>
> Can you try changing the alignment at include/libbb.h lines 1639 and
> 1640?
Changing alignment from 32 to 64 in these lines hasn't changed the behaviour.
Some more data points:
The disassembly of the code surrounding the crashing instruction is as
follows (crashing instruction marked with '=>'):
(gdb) disas
Dump of assembler code for function KeccakF:
0x10050b48 <+0>: stwu r1,-160(r1)
0x10050b4c <+4>: mflr r0
0x10050b50 <+8>: stmw r15,92(r1)
0x10050b54 <+12>: rlwinm r28,r5,3,0,28
0x10050b58 <+16>: add r30,r3,r28
0x10050b5c <+20>: stw r0,164(r1)
0x10050b60 <+24>: mr r31,r3
0x10050b64 <+28>: mr r29,r5
0x10050b68 <+32>: add r28,r4,r28
0x10050b6c <+36>: b 0x10050b94 <KeccakF+76>
=> 0x10050b70 <+40>: lwz r3,0(r28)
0x10050b74 <+44>: lwz r4,4(r28)
0x10050b78 <+48>: lwz r26,0(r30)
0x10050b7c <+52>: lwz r27,4(r30)
0x10050b80 <+56>: bl 0x1005a844 <bb_bswap_64>
0x10050b84 <+60>: xor r3,r3,r26
0x10050b88 <+64>: xor r4,r4,r27
0x10050b8c <+68>: stw r3,0(r30)
0x10050b90 <+72>: stw r4,4(r30)
0x10050b94 <+76>: addic. r29,r29,-1
0x10050b98 <+80>: addi r30,r30,-8
0x10050b9c <+84>: addi r28,r28,-8
0x10050ba0 <+88>: bge+ 0x10050b70 <KeccakF+40>
0x10050ba4 <+92>: lis r26,4113
0x10050ba8 <+96>: lis r22,4113
0x10050bac <+100>: addi r26,r26,20832
0x10050bb0 <+104>: li r28,0
0x10050bb4 <+108>: addi r30,r1,8
The content of the r28 register is:
(gdb) info registers
...
r28 0x10173010 269955088
The process' /proc/[pid]/maps file shows:
1014d000-10173000 rwxp 00000000 00:00 0 [heap]
which means that we're trying to read just beyond the process allocated heap.
>From the disassembly code I infer that the crash happens before the call to
bb_bswap_64 at address 0x10050b80.
I hope this helps.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
More information about the busybox
mailing list