2

Due to OSX having out of date openssl versions, i need to bundle more up to date copies of libssl and libcrypto with my application.

The bundled versions i distribute do appear to work on very recent systems (My own system and the system i built these libraries on is a 2015 MBP) - but on some other systems I get an 'illegal instruction' error using those bundled libraries.

My questions are:

(1) Are the illegal instructions happening because an advanced instruction (such as AVX-512) are being used by the binary, and this instructions doesn't exist on some systems?

(2) How do i build versions of libssl and libcrypto that can be bundled and used by the vast majority of relatively recent apple systems? (without causing illegal instructions..)

horseyguy
  • 29,455
  • 20
  • 103
  • 145
  • Nothing to do with AVX-512, as that's currently only found on the newly released iMac Pro. More likely to be an issue with AVX/AVX2 instructions, I would guess. What are the "other systems" exactly ? – Paul R Jan 30 '18 at 09:00
  • @PaulR one example is this MacPro3,1, BootROM MP31.006C.B05, 8 processors, Quad-Core Intel Xeon, 2.8 GHz, 24 GB, SMC 1.25f4, and other ones like MacBook Pro (13-inch, Early 2011), etc – horseyguy Jan 30 '18 at 09:04
  • OK - that's a Penryn "Harpertown" CPU, which has up to SSE 4.1, but no AVX/AVX2. You probably just need to make sure that your executable and libraries are all built for SSE4.1, rather than building them for whatever the native architecture is on your development machine. – Paul R Jan 30 '18 at 09:09
  • @PaulR thanks, i don't have experience doing that. Which flags should i provide? and are there any other things I should know about? – horseyguy Jan 30 '18 at 09:13
  • 1
    Sorry - I've never built libssl/libcrypto, but you should be able to set appropriate options to ./configure (or whatever build system they use). For the executable, assuming you're using Xcode, then there's a build setting `CLANG_X86_VECTOR_INSTRUCTIONS` (just type "VEC" in the build settings search box). – Paul R Jan 30 '18 at 09:44

1 Answers1

1

(1) Are the illegal instructions happening because an advanced instruction (such as AVX-512) are being used by the binary, and this instructions doesn't exist on some systems?

It depends, and you probably need to show the code that's causing them. In the past OpenSSL used CPU feature probes to see what was available on all (nearly all?) platforms. Also see questions like SSL_library_init cause SIGILL when running under gdb.

In the latest sources OpenSSL does not perform CPU feature probes on Apple platforms because a SIGILL trashes memory. It is some sort of Apple bug and it affects Botan, Crypto++, OpenSSL and others probing the cpu. (All the listed libraries moved away from Apple feature probes). That's a recent change, however. Also see OpenSSL PR 3108, SIGILL-free processor capabilities detection on MacOS X.

(2) How do i build versions of libssl and libcrypto that can be bundled and used by the vast majority of relatively recent apple systems?

If you are not doing so, use the latest OpenSSL. That should avoid the cpu feature probes on Apple platforms.

The library also uses -force_cpusubtype_ALL, so the compile should target the least capable machine in a class of cpu's. That should be enough to avoid instructions not available on later cpu's.

If the project is using AVX-512, then it's use is certainly guarded at runtime. My guess is the guard likely checks the result of CPUID. We would need to see the code in question that is using AVX-512 instructions and causing the SIGILL to say more. But like I said, it is only a guess until we see the code.

jww
  • 97,681
  • 90
  • 411
  • 885
  • hey homie. thanks for your reply. Ultimately i fixed it by passing the `-nosse2` flag to `./Configure` see here: https://github.com/openssl/openssl/blob/master/INSTALL#L391-L404 I find it odd that it works though as i was getting 'illegal instruction' errors on architectuers that absolutely support sse2, so i think that flag does more than it says it does, and probably disables other advanced kind of instructions over and above sse2. Do you know anything about this and why it works? – horseyguy Jan 31 '18 at 12:48
  • @horseyguy - I have never used `-nosse2`, but it sounds like it in intended to treat early SSE2 support. Around 2000 or so SSE2 became an CPU feature. But the OS had to support SSE2 too, because the OS had to save floating point registers when using sse registers. It was like a context switch for the SIMD unit because they shared a register file. The context switch is the reason for `xsave` and `xstore` instructions. The description in the page you linked sounds a little off to me. I think you are right when you say *" ... I think that flag does more than it says it does..."*. – jww Jan 31 '18 at 17:43
  • https://github.com/openssl/openssl/blob/85d6ad34aa0158fb25538e116e611e6b858d3638/INSTALL#L391-L404 permanent link to the -nosse2 flag – leezu Jan 23 '20 at 23:18