No, it's definitely Rust's runtime doing this, somehow.
I have observed this behavior also. It happens with a program as simple as fn main() {}
.
$ printf 'fn main() {}\n' > test-rust.rs
$ rustc --version
rustc 1.59.0
$ rustc -g -O test-rust.rs -o test-rust
$ strace -e trace=openat,read ./test-rust
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\237\2\0\0\0\0\0"..., 832) = 832
openat(AT_FDCWD, "/proc/self/maps", O_RDONLY|O_CLOEXEC) = 3
read(3, "561342b1d000-561342b23000 r--p 0"..., 1024) = 1024
read(3, "0000-7f33e4d24000 r--p 00214000 "..., 1024) = 1024
read(3, "linux-x86-64.so.2\n7f33e4d89000-7"..., 1024) = 823
+++ exited with 0 +++
Compare what happens with the equivalent C program:
$ printf 'int main(void) { return 0; }\n' > test-c.c
$ gcc -O2 -g test-c.c -Wl,--no-as-needed -lgcc_s -o test-c
$ strace -e trace=openat,read ./test-c
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\237\2\0\0\0\0\0"..., 832) = 832
+++ exited with 0 +++
So we can rule out both glibc and libgcc_s (the stack unwinder, iirc).