Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2014 18:31:40 GMT
From:      Francois Tigeot <ftigeot@wolfpond.org>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   ports/185826: Programs using security/cryptopp crash with illegal instructions
Message-ID:  <201401161831.s0GIVeK5068412@oldred.freebsd.org>
Resent-Message-ID: <201401161840.s0GIe0Ec093438@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         185826
>Category:       ports
>Synopsis:       Programs using security/cryptopp crash with illegal instructions
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 16 18:40:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator:     Francois Tigeot
>Release:        DragonFly 3.7-DEVELOPMENT
>Organization:
>Environment:
DragonFly sekishi.zefyris.com 3.7-DEVELOPMENT DragonFly v3.7.1.509.g52b954-DEVELOPMENT #375: Sun Jan 12 13:04:22 CET 2014     ftigeot@sekishi.zefyris.com:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64
>Description:
While investigating net-p2p/amule crashes, I found out the security/cryptopp package tried to use illegal instructions.

This occurs in the CryptoPP::RandomNumberGenerator::GenerateWord32(unsigned int, unsigned int) method.

And is caused by the use of the shrx x86 instruction:

(gdb output)
Program received signal SIGILL, Illegal instruction.
0x0000000000626b88 in CryptoPP::RandomNumberGenerator::GenerateWord32(unsigned int, unsigned int) ()
=> 0x0000000000626b88 <_ZN8CryptoPP21RandomNumberGenerator14GenerateWord32Ejj+40>: c4 e2 73 f7 c3 shrx %ecx,%ebx,%eax

shrx is a new Haswell instruction, which means programs using the cryptopp library will crash on all machines not using this latest Intel processor generation.


>How-To-Repeat:
Build a cryptopp package on a Haswell CPU and try to use it on a machine with a previous generation CPU.
>Fix:
The root of the issue comes from the CXXFLAGS line in GNUmakefile.
Changing it to stop generating instructions for a particular CPU model (removing "-native") will fix packages once and for all. 

The attached patch fixes the issue for me.

Patch attached with submission follows:

--- GNUmakefile.orig	2014-01-16 18:14:51.544855000 +0000
+++ GNUmakefile
@@ -38,8 +38,6 @@ GAS219_OR_LATER = $(shell $(CXX) -xc -c
 ifneq ($(GCC42_OR_LATER),0)
 ifeq ($(UNAME),Darwin)
 CXXFLAGS += -arch x86_64 -arch i386
-else
-CXXFLAGS += -march=native
 endif
 endif
 


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201401161831.s0GIVeK5068412>