[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