Re: [owl-users] tcb and friends with shadow-utils 4.0.12

From: Solar Designer (solar@private)
Date: Mon Jul 03 2006 - 23:30:36 PDT


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