Re: [PATCH] sha3sum: New applet, v2
>> $ file ./busybox >> ./busybox: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 >> (SYSV), statically linked, for GNU/Linux 2.6.9, stripped > > "MSB executable" means big-endian, isn't it? That's correct ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
> A pessimized build give the exact same result. Details below: Thanks Baruch. It's as I thought - something gives it wrong arguments. See here: > #1 0x1009dab4 in sha3_hash (state=0xbfca1fc0, data=0x101cafd0 "", > bytes=21474836485) > at libbb/hash_md5_sha.c:1055 bytes is 20 Gb (!), yet the memory pointed to by data is a few bytes long only. I think I know why, size_t on your platform is not 64-bit, will post a v3 soon. - Lauri -- http://www.fastmail.fm - A fast, anti-spam email service. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
> > # mips64 > > $ echo "Hello World" | ./busybox sha3sum > > bb5596c9990b5e6f821d17150b3c79585180ed05f4570ba82a89816a5680c463d3ce23fa8daff68e0ada7c235e21f619d5fc0e122ee2e5fe959e004742d53ee4 > > # x86_64 > > $ echo "Hello World" | ./busybox sha3sum > > 9ad2496364575076338331ca40a51a46d6a1d680c4e4d31bc3db6f4e46a5de376e0289692dbbb85fec8d9843f7c0a7efe200e86f2382c07d0674d20862db72d8 > > - > > Is there an independent, publicly available implementation of SHA-3 that > would > tell us which one is correct? I used the prints on Wikipedia to test - the SHA-3 page lists the sums for an empty string, the lazy fox sentence, and the lazy fox sentence with a dot added. All three match with this implementation (when run on x86_64). - Lauri -- http://www.fastmail.fm - The way an email service should be ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Tue, Jan 08, 2013 at 09:34:49AM +0200, Baruch Siach wrote:
> On Sun, Jan 06, 2013 at 10:04:36PM +0200, Lauri Kasanen wrote:
> > > The content of the r28 register is:
> > >
> > > (gdb) info registers
> > > ...
> > > r280x10173010 269955088
> > >
> > > The process' /proc/[pid]/maps file shows:
> > >
> > > 1014d000-10173000 rwxp 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.
> >
> > Thanks.
> >
> > Can you also enable CONFIG_PESSIMIZE (disable gcc's optimization) and
> > post the backtrace? I wonder if somehow it gets called with wrong
> > arguments (end of string, but wrong size for example), those were
> > optimized out in the first backtrace.
>
> A pessimized build give the exact same result. Details below:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x1009d288 in KeccakF (state=0xbfca1fc0, in=0x101cafd0, laneCount=8)
> at libbb/hash_md5_sha.c:977
> 977 state[laneCount] ^= SWAP_LE64(in[laneCount]);
> (gdb) bt
> #0 0x1009d288 in KeccakF (state=0xbfca1fc0, in=0x101cafd0, laneCount=8)
> at libbb/hash_md5_sha.c:977
> #1 0x1009dab4 in sha3_hash (state=0xbfca1fc0, data=0x101cafd0 "",
> bytes=21474836485)
> at libbb/hash_md5_sha.c:1055
> #2 0x1007180c in hash_file (filename=0x10169fcc "-") at
> coreutils/md5_sha1_sum.c:151
> #3 0x10071b74 in md5_sha1_sum_main (argc=1, argv=0xbfca23e8)
> at coreutils/md5_sha1_sum.c:247
> #4 0x10002980 in run_applet_no_and_exit (applet_no=122, argv=0xbfca23e8)
> at libbb/appletlib.c:755
> #5 0x100029c4 in run_applet_and_exit (name=0xbfca2d14 "sha3sum",
> argv=0xbfca23e8)
> at libbb/appletlib.c:762
> #6 0x10002818 in busybox_main (argv=0xbfca23e8) at libbb/appletlib.c:727
> #7 0x100029ec in run_applet_and_exit (name=0xbfca2d0c "busybox",
> argv=0xbfca23e4)
> at libbb/appletlib.c:764
> #8 0x10002ad4 in main (argc=2, argv=0xbfca23e4) at libbb/appletlib.c:819
>
> (gdb) p &in[laneCount]
> $1 = (const uint64_t *) 0x101cb010
One more data point that might be relevant:
(gdb) p laneCount
$1 = 8
> (gdb) disas
> Dump of assembler code for function KeccakF:
> [...]
>0x1009d258 <+120>: lwz r9,72(r1)
>0x1009d25c <+124>: add r0,r9,r0
>0x1009d260 <+128>: mr r9,r0
>0x1009d264 <+132>: lwz r8,0(r9)
>0x1009d268 <+136>: lwz r9,4(r9)
>0x1009d26c <+140>: stw r8,88(r1)
>0x1009d270 <+144>: stw r9,92(r1)
>0x1009d274 <+148>: lwz r0,80(r1)
>0x1009d278 <+152>: rlwinm r0,r0,3,0,28
>0x1009d27c <+156>: lwz r9,76(r1)
>0x1009d280 <+160>: add r0,r9,r0
>0x1009d284 <+164>: mr r11,r0
> => 0x1009d288 <+168>: lwz r9,0(r11)
>0x1009d28c <+172>: lwz r10,4(r11)
>0x1009d290 <+176>: mr r3,r9
>0x1009d294 <+180>: mr r4,r10
>0x1009d298 <+184>: bl 0x100b0898
>0x1009d29c <+188>: mr r10,r4
>0x1009d2a0 <+192>: mr r9,r3
>0x1009d2a4 <+196>: lwz r0,88(r1)
>0x1009d2a8 <+200>: xor r0,r0,r9
>0x1009d2ac <+204>: stw r0,96(r1)
>0x1009d2b0 <+208>: lwz r8,92(r1)
>0x1009d2b4 <+212>: xor r8,r8,r10
>0x1009d2b8 <+216>: stw r8,100(r1)
>0x1009d2bc <+220>: lwz r9,96(r1)
>0x1009d2c0 <+224>: lwz r10,100(r1)
>
> (gdb) info reg
> [...]
> r110x101cb010 270315536
>
> # cat /proc/[pid]/maps
> [...]
> 101a5000-101cb000 rwxp 00:00 0 [heap]
>
> baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Sun, Jan 06, 2013 at 10:04:36PM +0200, Lauri Kasanen wrote:
> > The content of the r28 register is:
> >
> > (gdb) info registers
> > ...
> > r280x10173010 269955088
> >
> > The process' /proc/[pid]/maps file shows:
> >
> > 1014d000-10173000 rwxp 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.
>
> Thanks.
>
> Can you also enable CONFIG_PESSIMIZE (disable gcc's optimization) and
> post the backtrace? I wonder if somehow it gets called with wrong
> arguments (end of string, but wrong size for example), those were
> optimized out in the first backtrace.
A pessimized build give the exact same result. Details below:
Program received signal SIGSEGV, Segmentation fault.
0x1009d288 in KeccakF (state=0xbfca1fc0, in=0x101cafd0, laneCount=8)
at libbb/hash_md5_sha.c:977
977 state[laneCount] ^= SWAP_LE64(in[laneCount]);
(gdb) bt
#0 0x1009d288 in KeccakF (state=0xbfca1fc0, in=0x101cafd0, laneCount=8)
at libbb/hash_md5_sha.c:977
#1 0x1009dab4 in sha3_hash (state=0xbfca1fc0, data=0x101cafd0 "",
bytes=21474836485)
at libbb/hash_md5_sha.c:1055
#2 0x1007180c in hash_file (filename=0x10169fcc "-") at
coreutils/md5_sha1_sum.c:151
#3 0x10071b74 in md5_sha1_sum_main (argc=1, argv=0xbfca23e8)
at coreutils/md5_sha1_sum.c:247
#4 0x10002980 in run_applet_no_and_exit (applet_no=122, argv=0xbfca23e8)
at libbb/appletlib.c:755
#5 0x100029c4 in run_applet_and_exit (name=0xbfca2d14 "sha3sum",
argv=0xbfca23e8)
at libbb/appletlib.c:762
#6 0x10002818 in busybox_main (argv=0xbfca23e8) at libbb/appletlib.c:727
#7 0x100029ec in run_applet_and_exit (name=0xbfca2d0c "busybox",
argv=0xbfca23e4)
at libbb/appletlib.c:764
#8 0x10002ad4 in main (argc=2, argv=0xbfca23e4) at libbb/appletlib.c:819
(gdb) p &in[laneCount]
$1 = (const uint64_t *) 0x101cb010
(gdb) disas
Dump of assembler code for function KeccakF:
[...]
0x1009d258 <+120>: lwz r9,72(r1)
0x1009d25c <+124>: add r0,r9,r0
0x1009d260 <+128>: mr r9,r0
0x1009d264 <+132>: lwz r8,0(r9)
0x1009d268 <+136>: lwz r9,4(r9)
0x1009d26c <+140>: stw r8,88(r1)
0x1009d270 <+144>: stw r9,92(r1)
0x1009d274 <+148>: lwz r0,80(r1)
0x1009d278 <+152>: rlwinm r0,r0,3,0,28
0x1009d27c <+156>: lwz r9,76(r1)
0x1009d280 <+160>: add r0,r9,r0
0x1009d284 <+164>: mr r11,r0
=> 0x1009d288 <+168>: lwz r9,0(r11)
0x1009d28c <+172>: lwz r10,4(r11)
0x1009d290 <+176>: mr r3,r9
0x1009d294 <+180>: mr r4,r10
0x1009d298 <+184>: bl 0x100b0898
0x1009d29c <+188>: mr r10,r4
0x1009d2a0 <+192>: mr r9,r3
0x1009d2a4 <+196>: lwz r0,88(r1)
0x1009d2a8 <+200>: xor r0,r0,r9
0x1009d2ac <+204>: stw r0,96(r1)
0x1009d2b0 <+208>: lwz r8,92(r1)
0x1009d2b4 <+212>: xor r8,r8,r10
0x1009d2b8 <+216>: stw r8,100(r1)
0x1009d2bc <+220>: lwz r9,96(r1)
0x1009d2c0 <+224>: lwz r10,100(r1)
(gdb) info reg
[...]
r110x101cb010 270315536
# cat /proc/[pid]/maps
[...]
101a5000-101cb000 rwxp 00:00 0 [heap]
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Matthew, Lauri,
On Mon, Jan 07, 2013 at 08:32:44PM -0600, Matthew Stoltenberg wrote:
> On Fri, Jan 4, 2013 at 5:02 AM, Lauri Kasanen wrote:
> > v2:
>
> Hey Lauri,
>
> I've got a mips64 processor I'm trying your patch with...
>
> Here are the results I get using mips64 vs a basic centos5 x86_64 machine:
>
> # mips64
> $ echo "Hello World" | ./busybox sha3sum
> bb5596c9990b5e6f821d17150b3c79585180ed05f4570ba82a89816a5680c463d3ce23fa8daff68e0ada7c235e21f619d5fc0e122ee2e5fe959e004742d53ee4
> -
> $ file ./busybox
> ./busybox: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1
> (SYSV), statically linked, for GNU/Linux 2.6.9, stripped
"MSB executable" means big-endian, isn't it?
> # x86_64
> $ echo "Hello World" | ./busybox sha3sum
> 9ad2496364575076338331ca40a51a46d6a1d680c4e4d31bc3db6f4e46a5de376e0289692dbbb85fec8d9843f7c0a7efe200e86f2382c07d0674d20862db72d8
> -
Is there an independent, publicly available implementation of SHA-3 that would
tell us which one is correct?
baruch
> $ file ./busybox
> ./busybox: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
> for GNU/Linux 2.6.9, statically linked, stripped
>
> I'll watch the thread and try it out when you post another patch.
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
On Fri, Jan 4, 2013 at 5:02 AM, Lauri Kasanen wrote: > v2: Hey Lauri, I've got a mips64 processor I'm trying your patch with... Here are the results I get using mips64 vs a basic centos5 x86_64 machine: # mips64 $ echo "Hello World" | ./busybox sha3sum bb5596c9990b5e6f821d17150b3c79585180ed05f4570ba82a89816a5680c463d3ce23fa8daff68e0ada7c235e21f619d5fc0e122ee2e5fe959e004742d53ee4 - $ file ./busybox ./busybox: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, stripped # x86_64 $ echo "Hello World" | ./busybox sha3sum 9ad2496364575076338331ca40a51a46d6a1d680c4e4d31bc3db6f4e46a5de376e0289692dbbb85fec8d9843f7c0a7efe200e86f2382c07d0674d20862db72d8 - $ file ./busybox ./busybox: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, stripped I'll watch the thread and try it out when you post another patch. Matt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Sun, Jan 06, 2013 at 10:04:36PM +0200, Lauri Kasanen wrote:
> > The content of the r28 register is:
> >
> > (gdb) info registers
> > ...
> > r280x10173010 269955088
> >
> > The process' /proc/[pid]/maps file shows:
> >
> > 1014d000-10173000 rwxp 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.
>
> Thanks.
>
> Can you also enable CONFIG_PESSIMIZE (disable gcc's optimization) and
> post the backtrace? I wonder if somehow it gets called with wrong
> arguments (end of string, but wrong size for example), those were
> optimized out in the first backtrace.
Disabling optimization may make the bug disappear, as the compiler doesn't use
legitimate optimization opportunities.
I'll try a pessimized build when I'm back at work on Tuesday.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
> The content of the r28 register is: > > (gdb) info registers > ... > r280x10173010 269955088 > > The process' /proc/[pid]/maps file shows: > > 1014d000-10173000 rwxp 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. Thanks. Can you also enable CONFIG_PESSIMIZE (disable gcc's optimization) and post the backtrace? I wonder if somehow it gets called with wrong arguments (end of string, but wrong size for example), those were optimized out in the first backtrace. - Lauri -- http://www.fastmail.fm - Send your email first class ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
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=, laneCount=8)
> > at libbb/hash_md5_sha.c:977
> > 977 state[laneCount] ^= SWAP_LE64(in[laneCount]);
> > (gdb) bt
> > #0 KeccakF (state=0xbf8d1f30, in=, laneCount=8)
> > at libbb/hash_md5_sha.c:977
> > #1 0x10051474 in sha3_hash (state=0xbf8d1f30, data=0x10172fd0 "",
> > bytes=) at libbb/hash_md5_sha.c:1055
> > #2 0x1003b544 in hash_file (filename=)
> > at coreutils/md5_sha1_sum.c:151
> > #3 0x1003b7c4 in md5_sha1_sum_main (argc=,
> > argv=) 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>: stwur1,-160(r1)
0x10050b4c <+4>: mflrr0
0x10050b50 <+8>: stmwr15,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
=> 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
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>:addir30,r30,-8
0x10050b9c <+84>:addir28,r28,-8
0x10050ba0 <+88>:bge+0x10050b70
0x10050ba4 <+92>:lis r26,4113
0x10050ba8 <+96>:lis r22,4113
0x10050bac <+100>: addir26,r26,20832
0x10050bb0 <+104>: li r28,0
0x10050bb4 <+108>: addir30,r1,8
The content of the r28 register is:
(gdb) info registers
...
r280x10173010 269955088
The process' /proc/[pid]/maps file shows:
1014d000-10173000 rwxp 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{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
> > > 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=, laneCount=8) > at libbb/hash_md5_sha.c:977 > 977 state[laneCount] ^= SWAP_LE64(in[laneCount]); > (gdb) bt > #0 KeccakF (state=0xbf8d1f30, in=, laneCount=8) > at libbb/hash_md5_sha.c:977 > #1 0x10051474 in sha3_hash (state=0xbf8d1f30, data=0x10172fd0 "", > bytes=) at libbb/hash_md5_sha.c:1055 > #2 0x1003b544 in hash_file (filename=) > at coreutils/md5_sha1_sum.c:151 > #3 0x1003b7c4 in md5_sha1_sum_main (argc=, > argv=) 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? - Lauri -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Sun, Jan 06, 2013 at 01:03:58PM +0200, Baruch Siach wrote:
> On Sun, Jan 06, 2013 at 01:00:30PM +0200, Lauri Kasanen wrote:
> > On Sun, Jan 6, 2013, at 7:18, Baruch Siach wrote:
> > > Hi Lauri,
> > > Testing on a big-endian system (PowerPC) I'm getting:
> > >
> > > # echo test |./busybox sha3sum
> > > Segmentation fault (core dumped)
> > >
> > > On a PC I get:
> > >
> > > $ echo test |./busybox sha3sum
> > > a5c3e353a185244f82a8de017db6022543d776f8943b457b6368c80854ecdfda1705e5dd514d5087116daccb7dace5ad42ab172bfe79a2c00b7a1e9c76e46b55
> > > -
> > >
> > > Any suggestion?
> >
> > 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=, laneCount=8)
at libbb/hash_md5_sha.c:977
977 state[laneCount] ^= SWAP_LE64(in[laneCount]);
(gdb) bt
#0 KeccakF (state=0xbf8d1f30, in=, laneCount=8)
at libbb/hash_md5_sha.c:977
#1 0x10051474 in sha3_hash (state=0xbf8d1f30, data=0x10172fd0 "",
bytes=) at libbb/hash_md5_sha.c:1055
#2 0x1003b544 in hash_file (filename=)
at coreutils/md5_sha1_sum.c:151
#3 0x1003b7c4 in md5_sha1_sum_main (argc=,
argv=) at coreutils/md5_sha1_sum.c:247
#4 0x1000240c in run_applet_no_and_exit (applet_no=,
argv=0xbf8d2378) at libbb/appletlib.c:755
#5 0x1000243c in run_applet_and_exit (name=0xbf8d2d14 "sha3sum",
argv=0xbf8d2378)
at libbb/appletlib.c:762
#6 0x10002610 in busybox_main (name=, argv=)
at libbb/appletlib.c:727
#7 run_applet_and_exit (name=, argv=)
at libbb/appletlib.c:764
#8 0x100026b4 in main (argc=, argv=0xbf8d2374)
at libbb/appletlib.c:819
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Sun, Jan 06, 2013 at 01:00:30PM +0200, Lauri Kasanen wrote:
> On Sun, Jan 6, 2013, at 7:18, Baruch Siach wrote:
> > Hi Lauri,
> > Testing on a big-endian system (PowerPC) I'm getting:
> >
> > # echo test |./busybox sha3sum
> > Segmentation fault (core dumped)
> >
> > On a PC I get:
> >
> > $ echo test |./busybox sha3sum
> > a5c3e353a185244f82a8de017db6022543d776f8943b457b6368c80854ecdfda1705e5dd514d5087116daccb7dace5ad42ab172bfe79a2c00b7a1e9c76e46b55
> > -
> >
> > Any suggestion?
>
> 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.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
On Sun, Jan 6, 2013, at 7:18, Baruch Siach wrote: > Hi Lauri, > Testing on a big-endian system (PowerPC) I'm getting: > > # echo test |./busybox sha3sum > Segmentation fault (core dumped) > > On a PC I get: > > $ echo test |./busybox sha3sum > a5c3e353a185244f82a8de017db6022543d776f8943b457b6368c80854ecdfda1705e5dd514d5087116daccb7dace5ad42ab172bfe79a2c00b7a1e9c76e46b55 > - > > Any suggestion? 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 - Lauri -- http://www.fastmail.fm - A fast, anti-spam email service. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] sha3sum: New applet, v2
Hi Lauri,
On Fri, Jan 04, 2013 at 01:02:53PM +0200, Lauri Kasanen wrote:
> From 84768213e7a004b9e703a1d7091bd43b34822e0c Mon Sep 17 00:00:00 2001
> From: Lauri Kasanen
> Date: Thu, 3 Jan 2013 21:10:01 +0200
> Subject: [PATCH] sha3sum: New applet, v2
>
> - Sorted the enum by alpha (was sorted by algorithm age)
> - Use normal rotate here, xor not needed
> - Comment cleanup
> - Remove *empty* comments
> - Unify one be/le path
> - Remove #define round
> - Move to if(BB_ENDIAN) instead of #if
Testing on a big-endian system (PowerPC) I'm getting:
# echo test |./busybox sha3sum
Segmentation fault (core dumped)
On a PC I get:
$ echo test |./busybox sha3sum
a5c3e353a185244f82a8de017db6022543d776f8943b457b6368c80854ecdfda1705e5dd514d5087116daccb7dace5ad42ab172bfe79a2c00b7a1e9c76e46b55
-
Any suggestion?
baruch
> Signed-off-by: Lauri Kasanen
> ---
> coreutils/Config.src | 12 ++-
> coreutils/Kbuild.src |1 +
> coreutils/md5_sha1_sum.c | 17
> include/applets.src.h|1 +
> include/libbb.h |7 ++
> libbb/hash_md5_sha.c | 212
> ++
> testsuite/sha3sum.tests |3 +
> 7 files changed, 250 insertions(+), 3 deletions(-)
> create mode 100755 testsuite/sha3sum.tests
>
> diff --git a/coreutils/Config.src b/coreutils/Config.src
> index a28449b..0c44c4b 100644
> --- a/coreutils/Config.src
> +++ b/coreutils/Config.src
> @@ -514,6 +514,12 @@ config SHA512SUM
> help
> Compute and check SHA512 message digest
>
> +config SHA3SUM
> + bool "sha3sum"
> + default y
> + help
> + Compute and check SHA3 (512-bit) message digest
> +
> config SLEEP
> bool "sleep"
> default y
> @@ -766,13 +772,13 @@ config FEATURE_HUMAN_READABLE
> help
> Allow df, du, and ls to have human readable output.
>
> -comment "Common options for md5sum, sha1sum, sha256sum, sha512sum"
> - depends on MD5SUM || SHA1SUM || SHA256SUM || SHA512SUM
> +comment "Common options for md5sum, sha1sum, sha256sum, sha512sum, sha3sum"
> + depends on MD5SUM || SHA1SUM || SHA256SUM || SHA512SUM || SHA3SUM
>
> config FEATURE_MD5_SHA1_SUM_CHECK
> bool "Enable -c, -s and -w options"
> default y
> - depends on MD5SUM || SHA1SUM || SHA256SUM || SHA512SUM
> + depends on MD5SUM || SHA1SUM || SHA256SUM || SHA512SUM || SHA3SUM
> help
> Enabling the -c options allows files to be checked
> against pre-calculated hash values.
> diff --git a/coreutils/Kbuild.src b/coreutils/Kbuild.src
> index d6453f0..b715b9c 100644
> --- a/coreutils/Kbuild.src
> +++ b/coreutils/Kbuild.src
> @@ -62,6 +62,7 @@ lib-$(CONFIG_SEQ) += seq.o
> lib-$(CONFIG_SHA1SUM) += md5_sha1_sum.o
> lib-$(CONFIG_SHA256SUM) += md5_sha1_sum.o
> lib-$(CONFIG_SHA512SUM) += md5_sha1_sum.o
> +lib-$(CONFIG_SHA3SUM) += md5_sha1_sum.o
> lib-$(CONFIG_SLEEP) += sleep.o
> lib-$(CONFIG_SPLIT) += split.o
> lib-$(CONFIG_SORT) += sort.o
> diff --git a/coreutils/md5_sha1_sum.c b/coreutils/md5_sha1_sum.c
> index 2cb6dd4..b62e7c2 100644
> --- a/coreutils/md5_sha1_sum.c
> +++ b/coreutils/md5_sha1_sum.c
> @@ -55,6 +55,16 @@
> //usage: "\n -s Don't output anything, status code shows
> success"
> //usage: "\n -w Warn about improperly formatted checksum lines"
> //usage: )
> +//usage:
> +//usage:#define sha3sum_trivial_usage
> +//usage: IF_FEATURE_MD5_SHA1_SUM_CHECK("[-c[sw]] ")"[FILE]..."
> +//usage:#define sha3sum_full_usage "\n\n"
> +//usage: "Print" IF_FEATURE_MD5_SHA1_SUM_CHECK(" or check") " SHA3-512
> checksums"
> +//usage: IF_FEATURE_MD5_SHA1_SUM_CHECK( "\n"
> +//usage: "\n -c Check sums against list in FILEs"
> +//usage: "\n -s Don't output anything, status code shows
> success"
> +//usage: "\n -w Warn about improperly formatted checksum lines"
> +//usage: )
>
> #include "libbb.h"
>
> @@ -65,6 +75,7 @@ enum {
> HASH_MD5 = 's', /* "md5>s HASH_SHA1 = '1',
> HASH_SHA256 = '2',
> + HASH_SHA3 = '3',
> HASH_SHA512 = '5',
> };
>
> @@ -86,6 +97,7 @@ static uint8_t *hash_file(const char *filename)
> {
> int src_fd, hash_len, count;
> union _ctx_ {
> + sha3_ctx_t sha3;
> sha512_ctx_t sha512;
> sha256_ctx_t sha256;
> sha1_ctx_t sha1;
> @@ -124,6 +136,11 @@ static uint8_t *hash_file(const char *filename)
> update = (void*)sha512_hash;
> final = (void*)sha512_end;
> hash_len = 64;
> + } else if (ENABLE_SHA3SUM && hash_algo == HASH_SHA3) {
> + sha3_begin(&context.sha3);
> + update = (void*)sha3_hash;
> + final = (void*)sha3_end;
> + hash_len = 64;
> } else {
> xfunc_die(); /* can't reach this */
> }
> diff --git a/include/applets.src.h b/include/applets.src.h
> index 597b1c9..29ab167 100644
> --- a/inclu
Re: [PATCH] sha3sum: New applet, v2
On Friday 04 January 2013 06:02:53 Lauri Kasanen wrote: > v2: > - Sorted the enum by alpha (was sorted by algorithm age) > - Use normal rotate here, xor not needed > - Comment cleanup > - Remove *empty* comments > - Unify one be/le path > - Remove #define round > - Move to if(BB_ENDIAN) instead of #if looks ok to me. i'll let it sit a while to see if anyone has any feedback first. > PS: There were existing #if blocks in the same file, just above in the > md5 code. The requirement felt kinda weird with those there... at least the BB_ENDIAN ones should get fixed. the MD5_SMALL one isn't easy to make work (see how it gets used in the middle of var decls). -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
