Illegal instruction error on Mac about x25519

[ankane]

Everything works well when line 39 of lib/x25519.rb is commented out.

[tarcieri]

Can you provide precise information about the model of Mac you're using or its CPU? You can look it up here:

https://everymac.com/ultimate-mac-lookup/

This library uses Intel-provided CPU detection code to detect whether you have a Haswell or newer CPU:

https://github.com/crypto-rb/x25519/blob/master/ext/x25519_precomputed/cputest.c

That code seems to be triggering an unhandled illegal instruction error, which is somewhat surprising since it came from Intel. I can see if they have an updated version of the same code.

I can confirm this code is working for me on Mojave (10.14), but I have a Kaby Lake CPU.

[ankane]

The processor is an Intel Core i5 (i5-3427U).

[tarcieri]

Interesting. That's an Ivy Bridge CPU (generation before the one that supports that backend):

https://ark.intel.com/products/64903/Intel-Core-i5-3427U-Processor-3M-Cache-up-to-2-80-GHz-

I will investigate.

[tarcieri]

Can you try running Ruby under gdb so we can figure out which instruction it's crashing on? (I thought it used to print this information by default)

Here's a quick guide:

https://blog.packagecloud.io/eng/2014/11/17/debugging-ruby-gem-segfault/

Here are some gdb commands you can try running which will provide more information.

Call frame info:

(gdb) info frame

Last instruction executed:

(gdb) layout asm

The latter in particular would be quite helpful.

[ankane]

Here's the C level backtrace if that's helpful. Will figure out how to get gdb and codesign to cooperate tomorrow.

-- Machine register context ------------------------------------------------
 rax: 0x0000000008401000 rbx: 0x0000000000100800 rcx: 0x000000007fbae3ff
 rdx: 0x00000000bfebfbff rdi: 0x00007fd76b8f3640 rsi: 0x0000000000000000
 rbp: 0x00007ffee724fa90 rsp: 0x00007ffee724fa88  r8: 0x00007fd76d872aa0
  r9: 0x0000000000000003 r10: 0x00007fd76b7c4fa0 r11: 0x0000000000000001
 r12: 0x00007fd76b407438 r13: 0x00007fd76b7d8570 r14: 0x0000000000000000
 r15: 0x00007fd76b407448 rip: 0x0000000108e3a3c7 rfl: 0x0000000000010246

-- C level backtrace information -------------------------------------------
0   ruby                                0x0000000108bad1c7 rb_vm_bugreport + 135
1   ruby                                0x0000000108a244f3 rb_bug_context + 467
2   ruby                                0x0000000108b1b6d1 sigill + 81
3   libsystem_platform.dylib            0x00007fff6977bb3d _sigtramp + 29
4   x25519_precomputed.bundle           0x0000000108e3a3c7 check_4th_gen_intel_core_features + 23
5   x25519_precomputed.bundle           0x0000000108e405bf mX25519_is_available + 15
6   ruby                                0x0000000108b9fcb7 vm_call_cfunc + 295
7   ruby                                0x0000000108b87df3 vm_exec_core + 12419
8   ruby                                0x0000000108b9a340 vm_exec + 144
9   ruby                                0x0000000108a75c55 rb_load_internal0 + 341
10  ruby                                0x0000000108a764fc rb_require_internal + 1724
11  ruby                                0x0000000108a75ce8 rb_f_require + 24
12  ruby                                0x0000000108b9fcb7 vm_call_cfunc + 295
13  ruby                                0x0000000108b87df3 vm_exec_core + 12419
14  ruby                                0x0000000108b9a340 vm_exec + 144
15  ruby                                0x0000000108a2e5b1 ruby_exec_internal + 177
16  ruby                                0x0000000108a2e4a8 ruby_run_node + 56
17  ruby                                0x00000001089afd4f main + 79

[tarcieri]

@ankane oh sorry, you'll probably want to use lldb instead of gdb. You might try disassemble --frame --bytes

[tarcieri]

I'm beginning to think the easiest way to resolve this particular issue is wrapping the detecting function with Signal.trap("ILL") { ... } and return false if this code encounters SIGILL, which should be a clear sign that we're not on Haswell or above.

[tarcieri]

Seems that's not possible...

can't trap reserved signal: SIGILL (ArgumentError)

[ankane]

Here's what I'm seeing with lldb.

Process 1446 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x000000010f6753c7 x25519_precomputed.bundle`check_4th_gen_intel_core_features + 23
x25519_precomputed.bundle`check_4th_gen_intel_core_features:
->  0x10f6753c7 <+23>: andnl  %eax, %ecx, %eax
    0x10f6753cc <+28>: jne    0x10f67540f               ; <+95>
    0x10f6753ce <+30>: xorl   %esi, %esi
    0x10f6753d0 <+32>: xorl   %ecx, %ecx
Target 0: (ruby) stopped.

disassemble --frame --bytes
x25519_precomputed.bundle`check_4th_gen_intel_core_features:
    0x10f6753b0 <+0>:   55              pushq  %rbp
    0x10f6753b1 <+1>:   48 89 e5        movq   %rsp, %rbp
    0x10f6753b4 <+4>:   53              pushq  %rbx
    0x10f6753b5 <+5>:   31 db           xorl   %ebx, %ebx
    0x10f6753b7 <+7>:   31 c9           xorl   %ecx, %ecx
    0x10f6753b9 <+9>:   b8 01 00 00 00  movl   $0x1, %eax
    0x10f6753be <+14>:  0f a2           cpuid  
    0x10f6753c0 <+16>:  31 f6           xorl   %esi, %esi
    0x10f6753c2 <+18>:  b8 00 10 40 08  movl   $0x8401000, %eax          ; imm = 0x8401000 
->  0x10f6753c7 <+23>:  c4 e2 70 f2 c0  andnl  %eax, %ecx, %eax
    0x10f6753cc <+28>:  75 41           jne    0x10f67540f               ; <+95>
    0x10f6753ce <+30>:  31 f6           xorl   %esi, %esi
    0x10f6753d0 <+32>:  31 c9           xorl   %ecx, %ecx
    0x10f6753d2 <+34>:  0f 01 d0        xgetbv 
    0x10f6753d5 <+37>:  b9 06 00 00 00  movl   $0x6, %ecx
    0x10f6753da <+42>:  c4 e2 78 f2 c1  andnl  %ecx, %eax, %eax
    0x10f6753df <+47>:  75 2e           jne    0x10f67540f               ; <+95>
    0x10f6753e1 <+49>:  b8 07 00 00 00  movl   $0x7, %eax
    0x10f6753e6 <+54>:  31 db           xorl   %ebx, %ebx
    0x10f6753e8 <+56>:  31 c9           xorl   %ecx, %ecx
    0x10f6753ea <+58>:  0f a2           cpuid  
    0x10f6753ec <+60>:  31 f6           xorl   %esi, %esi
    0x10f6753ee <+62>:  b8 28 01 00 00  movl   $0x128, %eax              ; imm = 0x128 
    0x10f6753f3 <+67>:  c4 e2 60 f2 c0  andnl  %eax, %ebx, %eax
    0x10f6753f8 <+72>:  75 15           jne    0x10f67540f               ; <+95>
    0x10f6753fa <+74>:  b8 01 00 00 80  movl   $0x80000001, %eax         ; imm = 0x80000001 
    0x10f6753ff <+79>:  31 db           xorl   %ebx, %ebx
    0x10f675401 <+81>:  31 c9           xorl   %ecx, %ecx
    0x10f675403 <+83>:  0f a2           cpuid  
    0x10f675405 <+85>:  b8 05 01 00 00  movl   $0x105, %eax              ; imm = 0x105 
    0x10f67540a <+90>:  c4 e2 78 f7 f1  bextrl %eax, %ecx, %esi
    0x10f67540f <+95>:  89 f0           movl   %esi, %eax
    0x10f675411 <+97>:  5b              popq   %rbx
    0x10f675412 <+98>:  5d              popq   %rbp
    0x10f675413 <+99>:  c3              retq   
    0x10f675414 <+100>: 90              nop    
    0x10f675415 <+101>: 90              nop    
    0x10f675416 <+102>: 90              nop    
    0x10f675417 <+103>: 90              nop    
    0x10f675418 <+104>: 90              nop    
    0x10f675419 <+105>: 90              nop    
    0x10f67541a <+106>: 90              nop    
    0x10f67541b <+107>: 90              nop    
    0x10f67541c <+108>: 90              nop    
    0x10f67541d <+109>: 90              nop    
    0x10f67541e <+110>: 90              nop    
    0x10f67541f <+111>: 90              nop    

[tarcieri]

Okay, I think I've got a handle on it now. So the instruction it's crashing on (andnl) is a Haswell+ instruction:

https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1_(Bit_Manipulation_Instruction_Set_1)

...but that whole backend is being compiled assuming those instructions are available (and with aggressive optimizations), so the compiler is using them to optimize the CPU test.

The CPU test needs to be compiled for a more conservative march, possibly as its own .so

[ankane]

C is not my strong suit, but if there's anything else I can do to help, let me know. I appreciate all the help so far.

[ankane]

Just tried this on Ruby 2.7.1 (same machine and OS) and it's working now, so think we can close this out. Thanks for helping to dig into it!