Any interest in using the `linux-syscall` crate for syscall numbers?

[jmillikin]

In your recent Reddit post (https://www.reddit.com/r/rust/comments/1kocais/crate_update_how_to_block_or_intercept_specific/), I noticed this part:

the way syscalls enum is generated depends on your linux system because it parses your system headers at build time and it's prone to failure in some linux systems, so i would love to hear your feedback on this.

I maintain the crate linux-syscall, which contains a list of syscall numbers and a syscall!() macro for invoking them. The syscall numbers are generated separately and are checked in to source control, so there's no additional build step. My primary use case is the syscall!() macro, so I haven't thought about using it just as a source of syscall numbers until now.

If I were to update that crate to (1) add syscall number coverage for architectures without asm!() and (2) add a const method to extract the raw syscall number from the Syscall struct, would that be of any use to the restrict crate?

The example code would look something like this:

use linux_syscall as syscall;
use restrict::Policy;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Begin with everything allowed
    let mut policy = Policy::allow_all()?;

    // Block process creation and tracing
    policy
        .deny(syscall::SYS_execve)
        .deny(syscall::SYS_ptrace)
        .apply()?;  // Load the final rule set into the kernel

    // Your program continues here with the policy enforced
    Ok(())
}

[x0rw]

Hey @jmillikin .
Last week i planned to handle my syscalls in a different crate so i searched for the names 'syscall' and 'linux-syscall' in crates.io and i came across yours, i'm very open to the idea, if you want i could maintain it with you and possibly provide an egonomic arguments parser, and possibly SYS_ptrace => Ptrace for fluency,
Are you open to these changes?.

[jmillikin]

I'm not currently looking for a co-maintainer, though I appreciate the offer.

Adding new API would be OK if it's very small, but for more complex cases (such as fluent APIs) it would probably be better to keep those in the restrict crate. For example if you want an enum of supported/known syscalls then you could have that in restrict, and use linux-syscall just for the numbers.

The reason is that linux-syscall is designed to be both very thin and also easy to extend ad-hoc, for example using it for syscall numbers not yet assigned in the mainline kernel. That's why linux_syscall::Syscall is a struct with a public constructor.

Similarly, code that parses the arguments based on the syscall numbers would probably be best kept in this crate -- I'm not sure exactly what sort of work would be involved in that, but it feels like something that would need frequent updates as the kernel assigns new behaviors to existing syscalls.

[x0rw]

Great, currently i'm not facing any capabilities issues with the syscalls but there would be a lot later and i would think about it, the idea of having strongly-typed syscalls arguments requires either manual work which is a big no-no, or parsing the whole kernel source code for arguments and their structs for different archs.