Not working for 06cb:00be

[the-loudspeaker]

I am on a fedora 40 workstation on an Ideapad Flex 5 14ARE05.
Fingerprint device is 06cb:00be.

I installed lifprintd-tod, libfprintd-tod-devel and some other dependencies as suggested by meson build command.
Once meson build completed without errors, I followed rest of the instructions and installed the driver.

But even after installing this, I get the error as follows on fprintd-enroll:
Impossible to enroll: GDBus.Error:net.reactivated.Fprint.Error.NoSuchDevice: No devices available

I even tried rebooting & reinstalling again but same issue persists.

Am I missing anything? Please let me know if you need more info to debug this.

Thanks.

[Popax21]

The error is pretty self-explanatory: libfprint doesn't detect any supported devices. This means that either the driver doesn't get picked up, or you don't actually have a supported sensor (check lsusb for that).

[the-loudspeaker]

Sorry I forgot to mention the device id above.
here's the output of lsusb:
Bus 003 Device 002: ID 06cb:00be Synaptics, Inc.
As I understand this one is supported?

I read a post about it here: https://redlib.privacy.com.de/r/Ubuntu/comments/1185rx6/got_synaptic_fp_scanner_synaptics_06cb00be

[Popax21]

Sorry I forgot to mention the device id above. here's the output of lsusb: Bus 003 Device 002: ID 06cb:00be Synaptics, Inc. As I understand this one is supported?

I read a post about it here: https://redlib.privacy.com.de/r/Ubuntu/comments/1185rx6/got_synaptic_fp_scanner_synaptics_06cb00be

In that case it's probably the former; you might want to try reinstalling libfprint-tod / fprintd.

[jonastahl]

Unfortunately for me it's the same error with the same device.
I'm using it on Fedora 40 with libfprint-tod from "https://copr.fedorainfracloud.org/coprs/quantt/libfprint-tod/"
Also the fprintd run without problems. Do you have any suggestions on how to find the error from this point?

[Popax21]

Unfortunately for me it's the same error with the same device. I'm using it on Fedora 40 with libfprint-tod from "https://copr.fedorainfracloud.org/coprs/quantt/libfprint-tod/" Also the fprintd run without problems. Do you have any suggestions on how to find the error from this point?

You might want to try checking the system / fprintd log, and checking that it's actually libfprint-tod that is being used by fprintd, not libfprint.

[warthog9]

Jumping in here, hopefully with a bit more information. I've got the latest synaTudor 5e4df4061ef1cc67b504085806db35932a642aca and trying both the latest quantt libfprint-tod as well as compiling directly, no luck same as above.

That being said, poking around I'm seeing a core dump from a freshly compiled setup:

Dec 26 14:01:18 grogu audit[62916]: ANOM_ABEND auid=4294967295 uid=3333 gid=3333 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 pid=62916 comm="tudor_host" exe="/usr/sbin/tudor/tudor_host" sig=6 res=1
Dec 26 14:01:18 grogu systemd-coredump[62922]: Process 62916 (tudor_host) of user 3333 terminated abnormally with signal 6/ABRT, processing...
Dec 26 14:01:18 grogu systemd[1]: Started [email protected] - Process Core Dump (PID 62922/UID 0).
Dec 26 14:01:18 grogu audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@19-62922-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 26 14:01:18 grogu systemd[1]: Started [email protected] - Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Dec 26 14:01:18 grogu audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=drkonqi-coredump-processor@19-62922-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 26 14:01:18 grogu systemd-coredump[62930]: Process 62916 (tudor_host) of user 3333 dumped core.#012#012Module libudev.so.1 from rpm systemd-256.10-1.fc41.x86_64#012Module libz.so.1 from rpm zlib-ng-2.1.7-3.fc41.x86_64#012Module libseccomp.so.2 from rpm libseccomp-2.5.5-2.fc41.x86_64#012Module libcap.so.2 from rpm libcap-2.70-4.fc41.x86_64#012Module libusb-1.0.so.0 from rpm libusb1-1.0.27-4.fc41.x86_64#012Module libcrypto.so.3 from rpm openssl-3.2.2-9.fc41.x86_64#012Stack trace of thread 62920:#012#0  0x00007ff0d387f0f4 __pthread_kill_implementation (libc.so.6 + 0x730f4)#012#1  0x00007ff0d3825fde raise (libc.so.6 + 0x19fde)#012#2  0x00007ff0d380d942 abort (libc.so.6 + 0x1942)#012#3  0x0000000000405ee4 ipc_recv_msg (tudor_host + 0x5ee4)#012#4  0x0000000000401a02 get_pdata_cb (tudor_host + 0x1a02)#012#5  0x00007ff0d3f98eb7 tudor_reg_handler (libtudor.so + 0x29eb7)#012#6  0x00007ff0d3f79a96 winreg_query_val (libtudor.so + 0xaa96)#012#7  0x00007ff0d3f7a2f3 RegQueryValueExW (libtudor.so + 0xb2f3)#012#8  0x00007ff0d2e04184 n/a (n/a + 0x0)#012#9  0x0000000000000000 n/a (n/a + 0x0)#012#10 0x00007ff0bc000b70 n/a (n/a + 0x0)#012ELF object binary architecture: AMD x86-64
Dec 26 14:01:18 grogu abrt-dump-journal-core[5050]: Failed to obtain all required information from journald
Dec 26 14:01:18 grogu fprintd[62909]: Tudor host process died! Exit Code 134
Dec 26 14:01:18 grogu systemd[1]: [email protected]: Deactivated successfully.

or more, potentially usefully broken out:

           PID: 62916 (tudor_host)
           UID: 3333 (3333)
           GID: 3333 (3333)
        Signal: 6 (ABRT)
     Timestamp: Thu 2024-12-26 14:01:18 PST (4min 18s ago)
  Command Line: tudor_host
    Executable: /usr/sbin/tudor/tudor_host
 Control Group: /system.slice/tudor-host-launcher.service
          Unit: tudor-host-launcher.service
         Slice: system.slice
       Boot ID: 2ff77d9b176c4a458180bf9307e6c86c
    Machine ID: 03141c1e50594f9a9e6cf14994c747dd
      Hostname: grogu.not.afront.org
       Storage: /var/lib/systemd/coredump/core.tudor_host.3333.2ff77d9b176c4a458180bf9307e6c86c.62916.1735250478000000.zst (present)
  Size on Disk: 1.5M
       Message: Process 62916 (tudor_host) of user 3333 dumped core.

                Module libudev.so.1 from rpm systemd-256.10-1.fc41.x86_64
                Module libz.so.1 from rpm zlib-ng-2.1.7-3.fc41.x86_64
                Module libseccomp.so.2 from rpm libseccomp-2.5.5-2.fc41.x86_64
                Module libcap.so.2 from rpm libcap-2.70-4.fc41.x86_64
                Module libusb-1.0.so.0 from rpm libusb1-1.0.27-4.fc41.x86_64
                Module libcrypto.so.3 from rpm openssl-3.2.2-9.fc41.x86_64
                Stack trace of thread 62920:
                #0  0x00007ff0d387f0f4 __pthread_kill_implementation (libc.so.6 + 0x730f4)
                #1  0x00007ff0d3825fde raise (libc.so.6 + 0x19fde)
                #2  0x00007ff0d380d942 abort (libc.so.6 + 0x1942)
                #3  0x0000000000405ee4 ipc_recv_msg (tudor_host + 0x5ee4)
                #4  0x0000000000401a02 get_pdata_cb (tudor_host + 0x1a02)
                #5  0x00007ff0d3f98eb7 tudor_reg_handler (libtudor.so + 0x29eb7)
                #6  0x00007ff0d3f79a96 winreg_query_val (libtudor.so + 0xaa96)
                #7  0x00007ff0d3f7a2f3 RegQueryValueExW (libtudor.so + 0xb2f3)
                #8  0x00007ff0d2e04184 n/a (n/a + 0x0)
                #9  0x0000000000000000 n/a (n/a + 0x0)
                #10 0x00007ff0bc000b70 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64

unsurprisingly fprintd doesn't like it after that either, and it core dumps as well (that doesn't feel entirely pertinent but I can paste that out if it's helpful).

Not sure what it's doing without a lot more digging, but figured I'd report what I'm seeing on a possibly related issue

[warthog9]

Minor addition as I keep poking a bit:

warthog9@grogu:~/git/synaTudor/build$ /usr/sbin/tudor/tudor_cli temp1
>>>>> WARNING <<<<<
Even though the CLI employs sandboxing, its security is in no way comparable to the one found in the libfprint integration.
A malicious driver could take over your local user account!
This CLI is only intended to be used for debugging and/or small scale tests.
Press 'y' to continue, any key to exit: y
[INF] Initializing libcrypto...
[INF] Initializing libusb...
[INF] Found sensor USB device [bus 1 addr 5 vid 0x06cb pid 0x00be]
[INF] Opening sensor USB device...
[ERR] Error opening sensor USB device: -3 [LIBUSB_ERROR_ACCESS]
warthog9@grogu:~/git/synaTudor/build$

So it's finding it, attempts to open it, and then runs dead smack into a wall?

utterly wild guess from a completely uninformed me: guessing something changed in the windows driver and whatever we are using to query isn't doing it right? On that theory:

• ./build/libtudor/synaFpAdapter104.dll.p/installer.exe
• 09f06eac9464b0186c1b1c8ded7969a629372e1d789cfc6c8bd777c7275b698f ./build/libtudor/synaFpAdapter104.dll.p/installer.exe

[Popax21]

Minor addition as I keep poking a bit:

warthog9@grogu:~/git/synaTudor/build$ /usr/sbin/tudor/tudor_cli temp1
>>>>> WARNING <<<<<
Even though the CLI employs sandboxing, its security is in no way comparable to the one found in the libfprint integration.
A malicious driver could take over your local user account!
This CLI is only intended to be used for debugging and/or small scale tests.
Press 'y' to continue, any key to exit: y
[INF] Initializing libcrypto...
[INF] Initializing libusb...
[INF] Found sensor USB device [bus 1 addr 5 vid 0x06cb pid 0x00be]
[INF] Opening sensor USB device...
[ERR] Error opening sensor USB device: -3 [LIBUSB_ERROR_ACCESS]
warthog9@grogu:~/git/synaTudor/build$

So it's finding it, attempts to open it, and then runs dead smack into a wall?

utterly wild guess from a completely uninformed me: guessing something changed in the windows driver and whatever we are using to query isn't doing it right? On that theory:

* `./build/libtudor/synaFpAdapter104.dll.p/installer.exe`

* `09f06eac9464b0186c1b1c8ded7969a629372e1d789cfc6c8bd777c7275b698f  ./build/libtudor/synaFpAdapter104.dll.p/installer.exe`

You need to run the CLI as root / using sudo for it to work; this is briefly mentioned in the docs, I'm sorry for not making that more clear though.

utterly wild guess from a completely uninformed me: guessing something changed in the windows driver and whatever we are using to query isn't doing it right? On that theory:

The installer's .exe hash is checked during the build process, which rules out this option.

However, notice how the coredump's backtrace points to abort; this means that one of libtudor / tudor-host's internal sanity checks failed. You should see a log message right before the snippet you posted which contains additional information about this. Going of the backtrace, the check seems to lie within the IPC message handling code, which means something is going wrong in regards to the messages exchanged by the libfprint-tod module and tudor-host.

[warthog9]

ok doing tudor_cli with sudo got me to the point where I can talk to the device and make some headway (I.E. communication is happening and good)

and yeah there was some messages hidden by systemd/audit screaming up a storm:

Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Activated sandbox
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Received init message - USB device 1-5
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Initialized libcrypto
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: libusb: warning [op_init] sysfs not mounted
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Initialized libusb
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [WRN] PE file contains unsupported resource data directory!
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [WRN] PE file contains unsupported exception data directory!
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Loaded driver DLL 'synaFpAdapter104.dll' [186656 bytes]
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [WRN] PE file contains unsupported resource data directory!
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [WRN] PE file contains unsupported exception data directory!
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [WRN] Data directory 4 has invalid bounds! [end 0x17ebe0 > image end 0x17e000]
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Loaded driver DLL 'synaWudfBioUsb104.dll' [1567712 bytes]
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Initializing driver DLL 'synaFpAdapter104.dll'...
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Initializing driver DLL 'synaWudfBioUsb104.dll'...
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Initialized tudor driver
Dec 26 16:55:55 grogu tudor_host_launcher[70939]: [INF] Opened USB device
Dec 26 16:55:55 grogu kernel: usb 1-7: reset full-speed USB device number 5 using xhci_hcd
Dec 26 16:55:55 grogu kernel: usb 1-7: reset full-speed USB device number 5 using xhci_hcd
Dec 26 16:55:56 grogu tudor_host_launcher[70939]: [WRN] GetModuleHandleExW called with unsupported flag GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS! [addr=0x7f24e27e4710]
Dec 26 16:55:56 grogu tudor_host_launcher[70939]: [INF] Getting pairing data for sensor 'AAD<withholding in case this is important>'...
Dec 26 16:55:56 grogu tudor_host_launcher[70939]: [ERR] Invalid IPC message size: 0x4 (min 0x8, max 0x4008)

This is after a recent F41 upgrade (so newer libfprint, et all) and I noticed a recent bios upgrade for the machine itself (though I don't think that should have done anything to the fingerprint reader)

[Popax21]

Seems like some IPC messages are getting corrupted / delivered out-of-order. You might want to try deleting any existing pairing data (should be stored in /var/lib/tudor), however, if that doesn't fix it then this will require a more thorough investigation.

[warthog9]

Tried clearing it out but it ends up creating the same file, same sha256sum even, as before so tudor_cli is working as expected though, I was able to enroll, verify, and query the print

[Popax21]

Tried clearing it out but it ends up creating the same file, same sha256sum even, as before so tudor_cli is working as expected though, I was able to enroll, verify, and query the print

Sorry for the late reply; I was on break over the holiday seasons. Either way, something seems to be going wrong with the IPC between the libfprint module and the tudor-host. Could you add logging to send_ipc_msg (libfprint-tod/src/ipc.c) and ipc_recv_msg (tudor-host/src/ipc.c) to log the bytes of the message being sent / received respectively? If you don't feel familiar enough with the C language to modify the code yourself, please let me know, and I'll try to get a patch file prepared and sent your way.

[vnsugadev]

I have an similar device, I wonder if it'll work or not

[vnsugadev]

This works fine, thanks so much to the dev here! I wonder why the main branch does not have this by default

[vnsugadev]

For some reason after a day now, KDE shows "place the fingerprint" but when I do so nothing happens, not sure what's wrong.

[MrQubo]

For some reason after a day now, KDE shows "place the fingerprint" but when I do so nothing happens, not sure what's wrong.

I have the same problems from time to time. I think these are bugs in fprintd though.

[warthog9]

Ok sorry for my own delay, some work travel and such, so the dump has shifted some so I guess something is going on upstream in libfprintd (noting I'm on Fedora 41 - fprintd 1.94.4-1.fc41)

From the tudor_host side of things:

# coredumpctl dump 1641046
           PID: 1641046 (tudor_host)
           UID: 3333 (3333)
           GID: 3333 (3333)
        Signal: 31 (SYS)
     Timestamp: Sat 2025-01-25 14:39:41 PST (2min 0s ago)
  Command Line: tudor_host
    Executable: /usr/sbin/tudor/tudor_host
 Control Group: /system.slice/tudor-host-launcher.service
          Unit: tudor-host-launcher.service
         Slice: system.slice
       Boot ID: b6df8b2c677844e39f1c75b6d92078b3
    Machine ID: 03141c1e50594f9a9e6cf14994c747dd
      Hostname: grogu.not.afront.org
       Storage: /var/lib/systemd/coredump/core.tudor_host.3333.b6df8b2c677844e39f1c75b6d92078b3.1641046.1737844781000000.zst (present)
  Size on Disk: 1.6M
       Message: Process 1641046 (tudor_host) of user 3333 dumped core.

                Module libudev.so.1 from rpm systemd-256.10-1.fc41.x86_64
                Module libz.so.1 from rpm zlib-ng-2.1.7-3.fc41.x86_64
                Module libseccomp.so.2 from rpm libseccomp-2.5.5-2.fc41.x86_64
                Module libcap.so.2 from rpm libcap-2.70-4.fc41.x86_64
                Module libusb-1.0.so.0 from rpm libusb1-1.0.27-4.fc41.x86_64
                Module libcrypto.so.3 from rpm openssl-3.2.2-9.fc41.x86_64
                Stack trace of thread 1641063:
                #0  0x00007fa022cfcf2c __mmap (libc.so.6 + 0xf0f2c)
                #1  0x00007fa022c29909 getrandom_vdso (libc.so.6 + 0x1d909)
                #2  0x00007fa023004d8f ossl_pool_acquire_entropy (libcrypto.so.3 + 0x204d8f)
                #3  0x00007fa023017fd1 ossl_rand_get_entropy.isra.0 (libcrypto.so.3 + 0x217fd1)
                #4  0x00007fa022fff85b get_entropy (libcrypto.so.3 + 0x1ff85b)
                #5  0x00007fa0230001b5 ossl_prov_drbg_instantiate (libcrypto.so.3 + 0x2001b5)
                #6  0x00007fa02300106c drbg_ctr_instantiate_wrapper.lto_priv.0 (libcrypto.so.3 + 0x20106c)
                #7  0x00007fa022efc67d EVP_RAND_instantiate (libcrypto.so.3 + 0xfc67d)
                #8  0x00007fa022f62801 rand_new_drbg (libcrypto.so.3 + 0x162801)
                #9  0x00007fa022f62a2a RAND_get0_primary (libcrypto.so.3 + 0x162a2a)
                #10 0x00007fa022f632e8 RAND_get0_private (libcrypto.so.3 + 0x1632e8)
                #11 0x00007fa022f63468 RAND_priv_bytes_ex (libcrypto.so.3 + 0x163468)
                #12 0x00007fa022e4b6ce bnrand.lto_priv.0 (libcrypto.so.3 + 0x4b6ce)
                #13 0x00007fa022e4bac8 bnrand_range (libcrypto.so.3 + 0x4bac8)
                #14 0x00007fa022e9d980 ossl_ec_key_simple_generate_key (libcrypto.so.3 + 0x9d980)
                #15 0x00007fa022e93fed ossl_ec_key_gen (libcrypto.so.3 + 0x93fed)
                #16 0x00007fa022e94b3a EC_KEY_generate_key (libcrypto.so.3 + 0x94b3a)
                #17 0x00007fa022ffa990 ec_gen.lto_priv.0 (libcrypto.so.3 + 0x1fa990)
                #18 0x00007fa022f0d568 EVP_PKEY_generate (libcrypto.so.3 + 0x10d568)
                #19 0x00007fa023488270 p256_generate_key_pair (libtudor.so + 0x15270)
                #20 0x00007fa023486023 BCryptGenerateKeyPair (libtudor.so + 0x13023)
                #21 0x00007fa02234aae8 n/a (n/a + 0x0)
                #22 0x70ffffffff000000 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64
#

I'll note that I don't believe much of anything has changed on the system in the intervening time, other than updates and obviously the synaTudor code bse is still at 5e4df4061ef1cc67b504085806db35932a642aca and I've reverted out my changes to dump the messages (wasn't making great forward progress on that yet anyway) and flushed the build just to be sure it was fresh. This feels like something in the API is shifting under synaTudor.

I might try spinning up an F39 and F40 live environment and giving this a quick whirl going back and seeing if I can at least bound what's going on a bit better, since this used to work.

[Popax21]

Ok sorry for my own delay, some work travel and such, so the dump has shifted some so I guess something is going on upstream in libfprintd (noting I'm on Fedora 41 - fprintd 1.94.4-1.fc41)

From the tudor_host side of things:

# coredumpctl dump 1641046
           PID: 1641046 (tudor_host)
           UID: 3333 (3333)
           GID: 3333 (3333)
        Signal: 31 (SYS)
     Timestamp: Sat 2025-01-25 14:39:41 PST (2min 0s ago)
  Command Line: tudor_host
    Executable: /usr/sbin/tudor/tudor_host
 Control Group: /system.slice/tudor-host-launcher.service
          Unit: tudor-host-launcher.service
         Slice: system.slice
       Boot ID: b6df8b2c677844e39f1c75b6d92078b3
    Machine ID: 03141c1e50594f9a9e6cf14994c747dd
      Hostname: grogu.not.afront.org
       Storage: /var/lib/systemd/coredump/core.tudor_host.3333.b6df8b2c677844e39f1c75b6d92078b3.1641046.1737844781000000.zst (present)
  Size on Disk: 1.6M
       Message: Process 1641046 (tudor_host) of user 3333 dumped core.

                Module libudev.so.1 from rpm systemd-256.10-1.fc41.x86_64
                Module libz.so.1 from rpm zlib-ng-2.1.7-3.fc41.x86_64
                Module libseccomp.so.2 from rpm libseccomp-2.5.5-2.fc41.x86_64
                Module libcap.so.2 from rpm libcap-2.70-4.fc41.x86_64
                Module libusb-1.0.so.0 from rpm libusb1-1.0.27-4.fc41.x86_64
                Module libcrypto.so.3 from rpm openssl-3.2.2-9.fc41.x86_64
                Stack trace of thread 1641063:
                #0  0x00007fa022cfcf2c __mmap (libc.so.6 + 0xf0f2c)
                #1  0x00007fa022c29909 getrandom_vdso (libc.so.6 + 0x1d909)
                #2  0x00007fa023004d8f ossl_pool_acquire_entropy (libcrypto.so.3 + 0x204d8f)
                #3  0x00007fa023017fd1 ossl_rand_get_entropy.isra.0 (libcrypto.so.3 + 0x217fd1)
                #4  0x00007fa022fff85b get_entropy (libcrypto.so.3 + 0x1ff85b)
                #5  0x00007fa0230001b5 ossl_prov_drbg_instantiate (libcrypto.so.3 + 0x2001b5)
                #6  0x00007fa02300106c drbg_ctr_instantiate_wrapper.lto_priv.0 (libcrypto.so.3 + 0x20106c)
                #7  0x00007fa022efc67d EVP_RAND_instantiate (libcrypto.so.3 + 0xfc67d)
                #8  0x00007fa022f62801 rand_new_drbg (libcrypto.so.3 + 0x162801)
                #9  0x00007fa022f62a2a RAND_get0_primary (libcrypto.so.3 + 0x162a2a)
                #10 0x00007fa022f632e8 RAND_get0_private (libcrypto.so.3 + 0x1632e8)
                #11 0x00007fa022f63468 RAND_priv_bytes_ex (libcrypto.so.3 + 0x163468)
                #12 0x00007fa022e4b6ce bnrand.lto_priv.0 (libcrypto.so.3 + 0x4b6ce)
                #13 0x00007fa022e4bac8 bnrand_range (libcrypto.so.3 + 0x4bac8)
                #14 0x00007fa022e9d980 ossl_ec_key_simple_generate_key (libcrypto.so.3 + 0x9d980)
                #15 0x00007fa022e93fed ossl_ec_key_gen (libcrypto.so.3 + 0x93fed)
                #16 0x00007fa022e94b3a EC_KEY_generate_key (libcrypto.so.3 + 0x94b3a)
                #17 0x00007fa022ffa990 ec_gen.lto_priv.0 (libcrypto.so.3 + 0x1fa990)
                #18 0x00007fa022f0d568 EVP_PKEY_generate (libcrypto.so.3 + 0x10d568)
                #19 0x00007fa023488270 p256_generate_key_pair (libtudor.so + 0x15270)
                #20 0x00007fa023486023 BCryptGenerateKeyPair (libtudor.so + 0x13023)
                #21 0x00007fa02234aae8 n/a (n/a + 0x0)
                #22 0x70ffffffff000000 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64
#

I'll note that I don't believe much of anything has changed on the system in the intervening time, other than updates and obviously the synaTudor code bse is still at 5e4df4061ef1cc67b504085806db35932a642aca and I've reverted out my changes to dump the messages (wasn't making great forward progress on that yet anyway) and flushed the build just to be sure it was fresh. This feels like something in the API is shifting under synaTudor.

I might try spinning up an F39 and F40 live environment and giving this a quick whirl going back and seeing if I can at least bound what's going on a bit better, since this used to work.

Seems like this is related to the new VDSO getrandom implementation hitting one of the sandbox's seccomp filters; this should be addressed with commit 1d08e98.