Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Oct 2017 21:15:32 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Linux x86_64

On Thu, Oct 26, 2017 at 03:39:52PM +0200, altr@...2.de wrote:
> Zitat von Solar Designer <solar@...nwall.com>:
> 
> >In addition to my previous response:
> >
> >On Thu, Oct 26, 2017 at 01:19:17PM +0200, altr@...2.de wrote:
> >>/nfs__share/ae/cc/189/JohnTheRipper/src>CFLAGS="$CFLAGS $cflags
> >>-I$asx_prefix/include" LDFLAGS="$LDFLAGS $ldflags -L$asx_prefix/lib"
> >>OPENSSL_LIBS="$asx_pref
> >>ix/lib/libssl.a $asx_prefix/lib/libcrypto.a"
> >>OPENSSL_CFLAGS="-I$asx_prefix/include -L$asx_prefix/lib" ./configure
> >>--prefix="$asx_prefix"
> >>checking build system type... x86_64-unknown-linux-gnu
> >>checking host system type... x86_64-unknown-linux-gnu
> >
> >So this looks like a custom or at least unusual Linux distro (or at
> >least build of gcc), and you use custom build options.
> 
> The flags are for openssl only. It is openssl-1.0.2k in this case.

What's in the $CFLAGS $cflags and $LDFLAGS $ldflags environment
variables before you run the configure command?

> >>configure: Testing build host's native CPU features
> >>checking for Hyperthreading... yes
> >>checking for MMX... yes
> >>checking for SSE2... yes
> >>checking for SSSE3... no
> >
> >It is rather unusual to have a CPU supporting SSE2 yet not SSSE3 these
> >days.  I'd guess this non-detection of SSSE3 is a side-effect of the
> >overridden CFLAGS, but I can't reproduce it.  So are you actually on a
> >currently rare early x86-64 CPU from prior to 2006 or so?  What is it?
> 
> The OS is CentOS 4.1, the CPU has the ability, but the kernel is  
> unable to do ssse3:
> 
> model name      :       Intel(R) Xeon(R) CPU E5-4620 v2 @ 2.60GHz
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge  
> mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx lm  
> pni cx16 ts

I understand that a kernel this old wouldn't detect SSSE3, but that
doesn't mean JtR's configure also wouldn't, because SSSE3 doesn't
require any special support from the kernel to be usable in userspace.
(AVX does.  So you should be able to use up to SSE4.1 with this old
kernel, unfortunately not using this CPU's AVX support.)

I think the reason for non-detection of SSSE3+ here is old gcc: our
configure script test for SSSE3 tries to compile a tiny program that
uses an SSSE3 intrinsic.

So this is sort of "fine".  In fact, it might have saved you from worse
problems if the code compiled for AVX but failed to run on this kernel.

> >>configure: WARNING: No recognized optimization option present in CFLAGS
> >
> >So you'd have a highly unoptimal build, even if the build worked,
> >because of you having overridden the CFLAGS.
> 
> I like to append the options, how do I achieve this?

Per my testing, the only important option that is lost when you override
CFLAGS is -O2, so simply include -O2 in your own CFLAGS.  The rest of
our custom CFLAGS are added on top of those you specify.

> >None of this is directly related to the build failure, but it indicates
> >that your build is highly unusual in general.
> 
> The machines are rather old to ensure compatiblity for newer machines.  
> So upgrading is not an option.

CentOS 4.1 is ridiculously old for this hardware, not letting you use it
fully, but OK.  I'm surprised it runs there at all.  BTW, besides not
supporting AVX in the kernel and not supporting SSSE3+ in gcc, I guess
it also fails to enable turbo boost on these CPUs.

> >As to the build failure, what's your version of "make" - e.g., what does
> >"make -v" say?
> 
> GNU Make 3.80

OK, we might try to reproduce the problem with that.

Meanwhile, you may try newer GNU make and optionally newer gcc (but then
you'd have to disable AVX manually) in your home directory.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ