: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4
Quoted 1 line · James Morris
Have you noticed if this happens for any of the other crypto algorithms?
Just as a reminder, there is still an issue with extreme stack usage of some of the algorithms, depending on compiler version and flags.
The worst I have seen was around 16kb for twofish_setkey on 64 bit s390 with gcc-3.1 (iirc). Right now, I get up to 4kb for this function with gcc-3.3.1, which probably works but is definitely a bad sign. I've seen this as well on other architectures (iirc on x86_64), but not as severe.
Other algorithms are bad as well, these are the top scores from Jörn Engel's checkstack.pl (s390 64bit 2.6.1 gcc-3.3.1):
0x00000a twofish_setkey: lay %r15,-3960(%r15)
0x0026fc aes_decrypt: lay %r15,-1168(%r15)
0x000c0c aes_encrypt: lay %r15,-1000(%r15)
0x00000e sha512_transform: lay %r15,-936(%r15)
0x001292 test_deflate: lay %r15,-784(%r15)
0x0028a2 cast6_decrypt: lay %r15,-696(%r15)
0x00d1a0 twofish_encrypt: lay %r15,-664(%r15)
0x001b34 setkey: lay %r15,-656(%r15)
0x00e2b0 twofish_decrypt: lay %r15,-624(%r15)
0x000c9e cast6_encrypt: lay %r15,-600(%r15)
0x000014 sha1_transform: lay %r15,-504(%r15)
^
This is the stack size --------|
Arnd <><Quoted 16 lines · Arnd Bergmann
Quoted 1 line · James Morris
Have you noticed if this happens for any of the other crypto algorithms?
Just as a reminder, there is still an issue with extreme stack usage of some of the algorithms, depending on compiler version and flags.
The worst I have seen was around 16kb for
twofish_setkeyon 64 bit s390 with gcc-3.1 (iirc). Right now, I get up to 4kb for this function with gcc-3.3.1, which probably works but is definitely a bad sign. I've seen this as well on other architectures (iirc onx86_64), but not as severe.Other algorithms are bad as well, these are the top scores from Jörn Engel's checkstack.pl (s390 64bit 2.6.1 gcc-3.3.1):
Quoted 11 lines
0x00000a twofish_setkey: lay %r15,-3960(%r15) 0x0026fc aes_decrypt: lay %r15,-1168(%r15) 0x000c0c aes_encrypt: lay %r15,-1000(%r15) 0x00000e sha512_transform: lay %r15,-936(%r15) 0x001292 test_deflate: lay %r15,-784(%r15) 0x0028a2 cast6_decrypt: lay %r15,-696(%r15) 0x00d1a0 twofish_encrypt: lay %r15,-664(%r15) 0x001b34 setkey: lay %r15,-656(%r15) 0x00e2b0 twofish_decrypt: lay %r15,-624(%r15) 0x000c9e cast6_encrypt: lay %r15,-600(%r15) 0x000014 sha1_transform: lay %r15,-504(%r15)
I'm not seeing anything like this on x86 (e.g. stack usage is 8 bytes), and can't see an obvious way to fix the problem for your compiler.
- James
Signature · 2 lines
James Morris <[email protected]>
On Fri, 30 Jan 2004 11:57:20 -0500 (EST) James Morris <[email protected]> wrote:
| On Fri, 30 Jan 2004, Arnd Bergmann wrote: | | > James Morris wrote: | > > Have you noticed if this happens for any of the other crypto algorithms? | > | > Just as a reminder, there is still an issue with extreme stack usage | > of some of the algorithms, depending on compiler version and | > flags. | > | > The worst I have seen was around 16kb for twofish_setkey on 64 bit | > s390 with gcc-3.1 (iirc). Right now, I get up to 4kb for this | > function with gcc-3.3.1, which probably works but is definitely | > a bad sign. I've seen this as well on other architectures (iirc | > on x86_64), but not as severe. | > | > Other algorithms are bad as well, these are the top scores from | > Jörn Engel's checkstack.pl (s390 64bit 2.6.1 gcc-3.3.1): | > | > 0x00000a twofish_setkey: lay %r15,-3960(%r15) | > 0x0026fc aes_decrypt: lay %r15,-1168(%r15) | > 0x000c0c aes_encrypt: lay %r15,-1000(%r15) | > 0x00000e sha512_transform: lay %r15,-936(%r15) | > 0x001292 test_deflate: lay %r15,-784(%r15) | > 0x0028a2 cast6_decrypt: lay %r15,-696(%r15) | > 0x00d1a0 twofish_encrypt: lay %r15,-664(%r15) | > 0x001b34 setkey: lay %r15,-656(%r15) | > 0x00e2b0 twofish_decrypt: lay %r15,-624(%r15) | > 0x000c9e cast6_encrypt: lay %r15,-600(%r15) | > 0x000014 sha1_transform: lay %r15,-504(%r15) | | I'm not seeing anything like this on x86 (e.g. stack usage is 8 bytes), | and can't see an obvious way to fix the problem for your compiler.
Here's what I see on x86 and gcc 3.2 (for Linux 2.6.1). What Linux version of the code are you looking at?
$0x180,%esp: c01fd5aa <aes_encrypt+4/1750>
$0x1b0,%esp: c01fecfa <aes_decrypt+4/17da>
$0x230,%esp: c0206acd <test_deflate+b/2f8>
$0x10c,%esp: c0205c90 <test_hmac+6/4fc>
$0x1fc,%esp: c01e9ed8 <sha1_transform+4/178a>
$0x120,%esp: c01eb842 <sha256_transform+6/1ef0>
$0x384,%esp: c01ed988 <sha512_transform+4/17e8>
$0x10c,%esp: c01f1c90 <twofish_setkey+4/7480>
--
~Randy
kernel-janitors project: http://janitor.kernelnewbies.org/
Quoted 4 lines · Randy.Dunlap
Here's what I see on x86 and gcc 3.2 (for Linux 2.6.1). What Linux version of the code are you looking at?
Quoted 9 lines
$0x180,%esp:
c01fd5aa<aes_encrypt+4/1750>
$0x1b0,%esp:c01fecfa<aes_decrypt+4/17da>
$0x230,%esp:c0206acd<test_deflate+b/2f8>
$0x10c,%esp:c0205c90<test_hmac+6/4fc>
$0x1fc,%esp:c01e9ed8<sha1_transform+4/178a>
$0x120,%esp:c01eb842<sha256_transform+6/1ef0>
$0x384,%esp:c01ed988<sha512_transform+4/17e8>
$0x10c,%esp:c01f1c90<twofish_setkey+4/7480>
2.6.2-rc2-mm2 with gcc version 3.3.1 20030915 (Red Hat Linux 3.3.1-5)
- James
Signature · 2 lines
James Morris <[email protected]>
Quoted 16 lines · James Morris
Quoted 4 lines · Randy.Dunlap
Here's what I see on x86 and gcc 3.2 (for Linux 2.6.1). What Linux version of the code are you looking at?
Quoted 9 lines
$0x180,%esp:
c01fd5aa<aes_encrypt+4/1750>
$0x1b0,%esp:c01fecfa<aes_decrypt+4/17da>
$0x230,%esp:c0206acd<test_deflate+b/2f8>
$0x10c,%esp:c0205c90<test_hmac+6/4fc>
$0x1fc,%esp:c01e9ed8<sha1_transform+4/178a>
$0x120,%esp:c01eb842<sha256_transform+6/1ef0>
$0x384,%esp:c01ed988<sha512_transform+4/17e8>
$0x10c,%esp:c01f1c90<twofish_setkey+4/7480>
Quoted 2 lines
2.6.2-rc2-mm2 with gcc version 3.3.1 20030915 (Red Hat Linux 3.3.1-5)
Actually, 24 bytes (not 8):
c02120b0 <twofish_setkey>:
c02120b0: 55 push %ebp c02120b1: 57 push %edi c02120b2: 56 push %esi c02120b3: 53 push %ebx c02120b4: 83 ec 18 sub $0x18,%esp
- James
Signature · 2 lines
James Morris <[email protected]>