tarcieri
commented
3 years ago You can try setting X25519.provider to X25519::Provider::Ref10 explicitly and see if that solves your problem.
This gem uses runtime detection (i.e. via CPUID) in order to detect the presence of the requisite instructions:
https://github.com/RubyCrypto/x25519/blob/master/lib/x25519.rb#L33-L39
Here's the relevant code:
https://github.com/RubyCrypto/x25519/blob/master/ext/x25519_precomputed/cputest.c
Illegal instruction would indicate one (or more) of the following:
- an instruction is being emitted beyond the ones that
cputest.ctests for, which would indicate something likemarchbeing incorrectly configured in your build environment - something is wrong with
cputest.c, and it is giving a false positive for the requisite instructions. note thatcputest.cis provided by Intel - something in your environment is causing the CPUID instruction to misreport the available CPU features, e.g. virtualization
A possible thought is that the gem could have been installed+compiled on a later processor architecture randomly and is getting deployed via the cache onto an older one?
This should only matter if something like -march=native were used as part of the build, as otherwise the CPU features explicitly required by this crate are detected at runtime. Note that something like that would be outside the scope of this particular crate and would impact every native extension. However, in such a case the compiler is free to emit instructions which are native to the build host and may not be available once the binary is relocated.
Some helpful debugging info you could try collecting:
- The output of
X25519::Provider::Precomputed.available? - The value of
X25519.provider
fwininger
lamont-granquist
This is happening to us a bunch in CI on buidkite on centos-8, oracle-7, ubuntu-20.04, ubuntu-18.04 (but not ubuntu-21.04), debian-10, debian-11 (but not debian-9). I suspect it randomly has to do with the worker the job gets assigned to and the chipset being used on the worker. Since it is in buildkite though on CI and I don't have a local replication its difficult to attach gdb or anything like that.
It is also mutiple layers of tooling deep in our CI jobs framework. It looks like ultimately one of our gems requires net-ssh, when then requires and finds x25519 and tries to use it since its in the bundle.
The vendor/bundle is buildkite's gem caching mechanism. A possible thought is that the gem could have been installed+compiled on a later processor architecture randomly and is getting deployed via the cache onto an older one?