Support `x86_64-unknown-linux-none`

[briansmith]

The target was added in rust-lang/rust#125023 and is available in the latest Nightly builds. Use cargo +nightly build --target=x86_64-unknown-linux-none -Zbuild-std.

The libc crate does NOT support this target, so libc::syscall and libc::getrandom cannot be used on this target.

I am planning to support this target in ring soon.

[newpavlov]

I think #401 is relevant here. We need a way of doing raw syscalls for this. Ideally, it would be handled by the linux-raw-sys crate, but @sunfishcode is hesitant to add raw syscall functions to it.

[josephlr]

I think if we want to support this target, we should just write the inline assembly to invoke the x86_64 syscall instruction, and hardcode the raw syscall number (318).

I agre with @sunfishcode that supporting a general mechanism for invoking any syscall on any Linux CPU architecture is very complicated (vDSO, some syscalls may or may not return, vfork, inline assembly isn't stable on all architectures supported by Rust, etc...).

But the situation for getrandom(2) + x86_64 specifically is much simpler, Linux only uses syscall on x86_64, and x86_64 inline assembly is stable. So the implementation can just be:

const NR_GETRANDOM: u32 = 318;

pub fn getrandom_syscall(buf: &mut [MaybeUninit<u8>], flags: u32) -> isize {
    unsafe {
        let ret;
        asm!(
            "syscall",
            inlateout("rax") NR_GETRANDOM as isize => ret,
            in("rdi") buf.as_mut_ptr(),
            in("rsi") buf.len(),
            in("rdx") flags,
            lateout("rcx") _,
            lateout("r11") _,
            options(nostack, preserves_flags)
        );
        ret
    }
}

[newpavlov]

@josephlr
Hm, you are right. If the raw target is limited to x86-64 it would be the easiest way to do this.

We probably can do it for other target arches as well (on x86 we can just use int 0x80 for simplicity) and gate it behind a hypothetical linux_raw_syscall feature.

[sunfishcode]

In the PR, @morr0ne said that x86_64-unknown-linux-none won't have libc, so it's likely that many crates will use rustix for I/O on *-linux-none, so rustix will often be in people's dependency trees already. Perhaps that makes it feasible for getrandom to just use rustix::rand::getrandom_uninit on x86_64-unknown-linux-none.

If it were just getrandom it may seem ok to hard-code a little bit of asm, but if other crates start following this example and we end up with many crates doing their own syscall asms, I think that would be unfortunate. And, it's reasonable to anticipate more linux-none targets than just x86_64.

[puppymati]

In the PR, @morr0ne said that x86_64-unknown-linux-none won't have libc, so it's likely that many crates will use rustix for I/O on *-linux-none, so rustix will often be in people's dependency trees already. Perhaps that makes it feasible for getrandom to just use rustix::rand::getrandom_uninit on x86_64-unknown-linux-none.

The *-linux-none targets heavily rely on something like rustix to work; at the moment its basically guaranteed that rustix will already be in the dependency tree.

If it were just getrandom it may seem ok to hard-code a little bit of asm, but if other crates start following this example and we end up with many crates doing their own syscall asms, I think that would be unfortunate. And, it's reasonable to anticipate more linux-none targets than just x86_64.

The x86_64-unknown-linux-none target is just the first of other *-linux-none targets. I plan to implement at the very least aarch64 and riscv64gc targets. Using asm here would mean having to implement such syscall manually for each potential target.

[newpavlov]

rustix does a lot of things and it's a relatively big dependency (42k LoCs in src/ according to tokei). As I wrote in the other issue, I like rustix and use it in my projects, but it's often prohibitively big for certain things. getrandom is just one of the examples. Another example is the io-uring crate, it needs only 3 syscalls and it handles associated types by itself.

This is why I would strongly prefer to have raw syscalls in the linux-raw-sys crate. In my opinion, the safety arguments against it just don't hold water in the light of the libc::sycall existence. Yes, it's an extremely dangerous unsafe tool and most people should use rustix, but it does not mean it should not be exposed. Arguably, it's similar to how we often expose *-sys crates, while users are directed toward safe wrappers.

If raw syscalls will not be added to linux-raw-sys, then our next best option is to define raw syscalls by ourselves as proposed by @josephlr above. Outside of the x86 targets (if we do not want to use int 0x80), it's a relatively straightforward piece of code.

[briansmith]

@josephlr wrote:

I think if we want to support this target, we should just write the inline assembly to invoke the x86_64 syscall instruction, and hardcode the raw syscall number (318).

I agree with this suggestion, and this is what I'm planning to do in ring for all x86_64-*-linux-* targets.

getrandom shouldn't add rustix as a dependency for this.

At the most, we could have a feature flag to use rustix instead of the inline assembly support. I suspect there are reason why some rustix users would prefer this, e.g. if they are using rustix to port to a non-Linux OS. But there's a separate issue for rustix already, to track this.

If getrandom is going to have the inline assembly, it should use the inline assembly for all x86_64-*-linux-* targets and eliminate the libc dependency for these targets, so that it gets tested continuously.

[briansmith]

This is why I would strongly prefer to have raw syscalls in the linux-raw-sys crate.

I would rather not have getrandom depend on linux-raw-sys crate. Chances are high that there will be bugs in linux-raw-sys crate that will not affect getrandom but which would trigger dependency management tools, causing a lot of churn and wasted effort.

[newpavlov]

Chances are high that there will be bugs in linux-raw-sys crate that will not affect getrandom but which would trigger dependency management tools, causing a lot of churn and wasted effort.

I don't think it's likely. The crate is a largely automatic conversion of the Linux headers and has almost no issues in its tracker despite being used actively (mostly through rustix). Comparatively, libc is a more problematic dependency and it has caused several breakages in getrandom for various reasons.

I think that maintaining inline assembly for syscalls and syscall numbers (rant: I wish Linux had stable syscall numbers across targets...) for various targets should be outside of the getrandom's area of responsibility. Ideally, we need THE crate for doing raw Linux syscall stuff, which would be used across the crates ecosystem. linux-raw-sys looks like the best candidate for this right now.

[sunfishcode]

What are the practical problems with using rustix for just *-linux-none, and leaving the rest of getrandom as-is?

[briansmith]

@josephlr wrote:

But the situation for getrandom(2) + x86_64 specifically is much simpler, Linux only uses syscall on x86_64, and x86_64 inline assembly is stable. So the implementation can just be:

That would support the target when the dev/urandom fallback is disabled. When they added this target, I asked them to commit to a minimum kernel version that would include the getrandom syscall, but they didn't want to. Thus, the minimum kernel version should be assumed to be the same as the Rust project's minimum in general for x86_64-linux; i.e. a dev/urandom fallback would be needed for this target as well.

FYI: In ring, for *-*-linux-*, I am considering requiring the user to opt into a libstd dependency for the dev/urandom fallback, and implementing the syscall much like @josephlr proposed. I would be willing to help getrandom maintain a standalone syscall wrapper.

What are the practical problems with using rustix for just *-linux-none, and leaving the rest of getrandom as-is?

At least for me (ring), I don't want to (in some sense, can't) have divergent codepaths for the x86_64-*-linux-* targets (in configurations for which the dev/urandom fallback is disabled). I expect there will be many rustix-like things in the next few years, unless/until rustix becomes a rust-lang project.

[sunfishcode]

At least for me (ring), I don't want to (in some sense, can't) have divergent codepaths for the x86_64-*-linux-* targets. I expect there will be many rustix-like things in the next few years, unless/until rustix becomes a rust-lang project.

I'm not familiar with ring. What are the practical considerations around using different codepaths for the x86_64-*-linux-* targets?

I expect there will be many rustix-like things in the next few years, unless/until rustix becomes a rust-lang project.

If we only used rustix for *-linux-none, which very few people are using today, how much of a practical concern is this?

[newpavlov]

What are the practical problems with using rustix for just *-linux-none, and leaving the rest of getrandom as-is?

1. Complexity and general size. It increases compilation times and makes it harder to review code in security-sensitive settings.
2. It increases chances of accidentally pulling libc (e.g. by enabling features). You could cfg this out for *-linux-none targets, but it will make rustix less consistent (e.g. it will be strange if the use-libc feature will have no effect).
3. It has a relatively high MSRV, which is likely to be bumped in future. (This point will be no longer relevant after wide adoption of the MSRV-aware resolver)
4. It evolves faster than linux-raw-sys and has a much bigger API surface, which increases downstream maintenance burden and probability of introducing new bugs.

I will reverse the question: what are the practical problems with exposing raw syscall functions in linux-raw-sys? As I wrote above and in the rustix issue, I don't consider the safety argument valid. The only stumbling block which I see is the vDSO stuff on x86 targets. One potential solution for this is to use int 0x80 (or potentially sysenter) in linux-raw-sys and implement vDSO-based syscalls in a separate crate or leave it in rustix.

[briansmith]

If we only used rustix for *-linux-none, which very few people are using today, how much of a practical concern is this?

I am using *-linux-none without rustix for ring specifically for unspecified reasons.