I wrote: > > > http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/2.0-CURRENT/glibc/SOURCES/glibc-2.3-avx-suse-crypt_blowfish.patch?root=packages&rev=5738&view=markup > > > > This confirms my guess. This patch has: > > > > -#define BF_ASM 1 > > +#define BF_ASM 0 > > > > This disables the assembly implementation, thus avoiding the problem > > with BF_FRAME being too small. On Tue, Jul 04, 2006 at 12:18:00AM -0600, Vincent Danen wrote: > I noticed that part, but didn't think too much of it because I didn't > know what that was. I'm assuming then that, despite putting x86 into > the libcrypt-routines part of the Makefile, it wasn't actually being > used, correct? Exactly. > Ok, I see BF_FRAME is set to 0x200, but I have no idea what would be > sufficient to increase it too. Care to give me something I can replace > that with and recompile? As I wrote to you in a private e-mail - I suggest that you first try to set BF_FRAME really high - say, to 0x4000 - to confirm that this does indeed resolve the problem. Then decrease it to a value that is 0x100 to 0x200 bytes higher than the required minimum (such that it doesn't fail on another build with a similar version of gcc). > It would probably be faster than me > recompiling glibc a few times to find something suitable. Also from that private e-mail - You don't need to recompile your glibc just to test this initially. You can use "make check" within the crypt_blowfish directory. > I think one long weekend invested turned out not too bad. =) Yes. If I knew it'd take you an entire weekend, I'd offer to debug the problem on your system. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments
This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 23:31:26 PDT