-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux: try to use libc getrandom to allow interposition #78785
Conversation
r? @m-ou-se (rust_highfive has picked a reviewer for you, use r? to override) |
It might be a bit confusing if non-linux/android platforms have only Considering |
I thought about that. I was also looking at a few bare calls to |
Yeah, |
4a755ed
to
de12492
Compare
Done! |
@eddyb I guess it's debatable whether |
concat_idents!(SYS_, $name), | ||
$($arg_name as c_long),* | ||
) as $ret | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this work for sendfile? The sendfile64 libc wrapper is available on 32bit and 64bit. But on 64bit only the raw sendfile syscall is available since it's already 64bit-wide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The macro is assuming that the libc function name
matches SYS_name
exactly. We would need something new to deal with different names among libc and 32/64-bit syscalls.
It's also meant for cases where the function is relatively new, not yet in the minimum libc we intend to support, so the syscall is a fallback. I don't think that's the case for sendfile64
, because it has been around since glibc 2.3.
☔ The latest upstream changes (presumably #75272) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
We'll try to use a weak `getrandom` symbol first, because that allows things like `LD_PRELOAD` interposition. For example, perf measurements might want to disable randomness to get reproducible results. If the weak symbol is not found, we fall back to a raw `SYS_getrandom` call.
de12492
to
cd22381
Compare
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
@bors r+ |
📌 Commit cd22381 has been approved by |
Rollup of 11 pull requests Successful merges: - rust-lang#78361 (Updated the list of white-listed target features for x86) - rust-lang#78785 (linux: try to use libc getrandom to allow interposition) - rust-lang#78999 (stability: More precise location for deprecation lint on macros) - rust-lang#79039 (Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak) - rust-lang#79079 (Turn top-level comments into module docs in MIR visitor) - rust-lang#79114 (add trailing_zeros and leading_zeros to non zero types) - rust-lang#79131 (Enable AVX512 *epi64 variants by updating stdarch) - rust-lang#79133 (bootstrap: use the same version number for rustc and cargo) - rust-lang#79145 (Fix handling of panic calls) - rust-lang#79151 (Fix typo in `std::io::Write` docs) - rust-lang#79158 (type is too big -> values of the type are too big) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
fn getrandom( | ||
buffer: *mut libc::c_void, | ||
length: libc::size_t, | ||
flags: libc::c_uint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though this says c_uint
, in Miri we are seeing the flags
argument being passed as a ptr-sized value when dlsym
returns NULL. Before this change it was always of size 4. Did something go wrong with the type logic?
} else { | ||
syscall( | ||
concat_idents!(SYS_, $name), | ||
$($arg_name as c_long),* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably where all arguments are made ptr-sized. It is not clear to me what that is done (we do have proper type information after all!), nor why it should even be allowed. Isn't it UB when the caller and callee types do not match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to make sure they're all integral/pointer values that fit in a machine word. As long as that's the case, the exact type doesn't matter. The ABI of a variadic function like syscall
will just put each argument into their own register, extended to a usize
/c_long
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a guarantee made by C? For all ABIs? And what happens with the value that is passed, logically, to the syscall? It should get truncated to the smaller of "type used" and "type expected", I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose we do something like #79196.
We'll try to use a weak
getrandom
symbol first, because that allowsthings like
LD_PRELOAD
interposition. For example, perf measurementsmight want to disable randomness to get reproducible results. If the
weak symbol is not found, we fall back to a raw
SYS_getrandom
call.