[Bug]: SIGILL, `Illegal instruction` in `sha2::sha512::x86::sha512_compress_x86_64_avx` (caused by gather_data_sampling)

[kmille]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

28.2.0-1

What operating system are you using?

Other Linux

Operating System Version

Arch Linux

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

element-desktop should start normally.

Actual Behavior

My element-desktop crashes on Arch Linux during startup with an illegal instruction segfaul. There is an issue in the element-desktop tracker. The stacktrace in gdb shows sha2::sha512::x86::sha512_compress_x86_64_avx as root cause.

Testcase Gist URL

No response

Additional Information

Thread 1 "electron" received signal SIGILL, Illegal instruction.                                                                                                                                                                               
sha2::sha512::x86::sha512_compress_x86_64_avx (state=0x7fffffff7260, block=0x7fffffff71e0 b"X\002EOS]rZZra\001crS^\017cs\003ccP\001w{rR\\W^@BBwcE\000W]L\005\002", '6' <repeats 85 times>) at src/sha512/x86.rs:64
Downloading source file /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sha2-0.9.9/src/sha512/x86.rs                                                                                                                               
warning: 64     src/sha512/x86.rs: No such file or directory                                                                                                                                                                                   
(gdb) backtrace                                                                                                        
#0  sha2::sha512::x86::sha512_compress_x86_64_avx (state=0x7fffffff7260, block=0x7fffffff71e0 b"X\002EOS]rZZra\001crS^\017cs\003ccP\001w{rR\\W^@BBwcE\000W]L\005\002", '6' <repeats 85 times>) at src/sha512/x86.rs:64
#1  sha2::sha512::x86::sha512_compress_x86_64_avx2 (state=0x7fffffff7260, blocks=...) at src/sha512/x86.rs:33
#2  0x00007fff613269b0 in sha2::sha512::x86::compress (state=0x7fffffff7260, blocks=...) at src/sha512/x86.rs:21
#3  sha2::sha512::compress512 (state=0x7fffffff7260, blocks=...) at src/sha512.rs:261
#4  sha2::sha512::{impl#0}::update::{closure#0} (b=...) at src/sha512.rs:32
#5  block_buffer::BlockBuffer<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UTerm, typenum::bit::B1>, typenum:
:bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>>::input_blocks<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<
typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UTerm, typenum::bit::B1>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, sha2:
:sha512::{impl#0}::update::{closure_env#0}> (self=0x7fffffff72b0, input=..., f=...) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/block-buffer-0.9.0/src/lib.rs:81
#6  sha2::sha512::Engine512::update (self=0x7fffffff7260, input=...) at src/sha512.rs:32
#7  0x00007fff610f10f1 in sha2::sha512::{impl#3}::update<&generic_array::GenericArray<u8, typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::uint::UInt<typenum::
uint::UInt<typenum::uint::UTerm, typenum::bit::B1>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>, typenum::bit::B0>>> (self=0x7fffffff7260, input=0x7fffffff71e0)
    at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sha2-0.9.9/src/sha512.rs:68
#8  hmac::{impl#2}::new_from_slice<sha2::sha512::Sha512> (key=...) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hmac-0.11.0/src/lib.rs:163
#9  pbkdf2::pbkdf2<hmac::Hmac<sha2::sha512::Sha512>> (salt=..., res=..., password=..., rounds=<optimized out>) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pbkdf2-0.8.0/src/lib.rs:133
#10 seshat::index::encrypted_dir::EncryptedMmapDirectory::rederive_key (passphrase=..., salt=..., pbkdf_count=10000) at src/index/encrypted_dir.rs:507
#11 0x00007fff610ef34e in seshat::index::encrypted_dir::EncryptedMmapDirectory::load_store_key (key_file=..., passphrase=...) at src/index/encrypted_dir.rs:352
#12 0x00007fff60ec880c in seshat::index::encrypted_dir::EncryptedMmapDirectory::open_or_create<&&alloc::string::String> (path=<optimized out>, passphrase=..., key_derivation_count=10000)
    at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seshat-3.0.0/src/index/encrypted_dir.rs:214
#13 0x00007fff60f0c6f6 in seshat::index::Index::open_index<&&alloc::string::String> (path=0x7fffffff8ca8, schema=..., config=<optimized out>) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seshat-3.0.0/src/index/mod.rs:454
#14 seshat::index::Index::new<&&alloc::string::String> (path=0x7fffffff8ca8, config=0x7fffffff9220) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seshat-3.0.0/src/index/mod.rs:413
#15 0x00007fff60eded15 in seshat::database::Database::create_index<&alloc::string::String> (path=0x7fffffff71e0, config=0x1) at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seshat-3.0.0/src/database/mod.rs:242
#16 0x00007fff60edf27d in seshat::database::Database::new_with_config<&alloc::string::String> (path=<optimized out>, config=0x7fffffff9220)
    at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seshat-3.0.0/src/database/mod.rs:133
....

[hardfalcon]

I have not tested this, but my guess about the cause of this problem is:

• version 0.9.9 of the sha2 crate uses version 0.2.1 of the cpufeatures crate to determine if the AVX and/or AVX2 code paths can be used,
• version 0.2.1 of the cpufeatures crate contains a flawed detection routine for AVX2 (and FMA),
• this bug was fixed in version 0.2.3 of the cpufeatures crate (after the sha2 maintainers had found the issue),
• the sha2 crate was subsequently updated to use the fixed version of the cpufeatures crate from version 0.10.3 onwards.

//EDIT1: I think this is not an electron-specific bug, but rather a bug in Matrix' seshat crate (though I am wondering why version 0.9.5 of the sha2 crate is used even though version 3.0.0 of the seshat supposedly depends on version 0.9.5 of the sha2 crate).

/EDIT2: By the way, it seems that I had forgotten that I had already filed a bug about this with the element maintainers a few weeks ago.

[electron-issue-triage]

Hello @kmille. Thanks for reporting this and helping to make Electron better!

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

Now adding the blocked/need-repro Needs a test case to reproduce the bug label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

[kmille]

hm, kinda.. partially reproducable.. This seems to work:

curl -L https://archlinux.org/packages/extra/x86_64/element-desktop/download/ -o element-desktop.tar.zst
tar -xf element-desktop.tar.zst usr/lib/element/

kmille@linbox:tmp.3jQGvc3S2E qemu-x86_64 -cpu Skylake-Client-v4,-avx,-avx2,-sse3 /usr/lib/electron28/electron usr/lib/element/app.asar --disable-dev-mode
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsaves [bit 3]
zsh: illegal hardware instruction (core dumped)  qemu-x86_64 -cpu Skylake-Client-v4,-avx,-avx2,-sse3  usr/lib/element/app.asar

But even this does not work:

kmille@linbox:tmp.3jQGvc3S2E qemu-x86_64 /usr/bin/electron28 /usr/lib/element/app.asar
qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
zsh: segmentation fault (core dumped)  qemu-x86_64 /usr/bin/electron28 /usr/lib/element/app.asar

Running /usr/bin/electron28 /usr/lib/element/app.asar works.

[mlaurencin]

Hi @kmille unfortunately, because of time constraints, triaging code with third-party dependencies is usually not feasible for a small team like Electron's. A test case directly using Electron's binaries like this would better allow us to narrow in on the problem. Would you be able to follow up with a test like this?

I'm adding the blocked/need-info label for this reason. After you make a test case, please link to it in a follow-up comment.

Thanks in advance! Your help is appreciated.

[mlaurencin]

We haven't gotten a response to the question above. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.