Add AUDIT_ARCH_* constants from linux/audit.h

[fullzer4]

Description

Add missing AUDIT_ARCH_* architecture identification constants for Linux.

These constants are defined in the kernel's linux/audit.h and are used with seccomp BPF filters to validate system call architecture. They allow programs to ensure syscalls are being made from the expected architecture, which is critical for security-sensitive applications using seccomp.

This adds:

• 4 helper constants: __AUDIT_ARCH_64BIT, __AUDIT_ARCH_LE, __AUDIT_ARCH_CONVENTION_MASK, __AUDIT_ARCH_CONVENTION_MIPS64_N32
• 53 architecture constants: AUDIT_ARCH_X86_64, AUDIT_ARCH_AARCH64, AUDIT_ARCH_ARM, etc.

These constants have existed in the kernel for years but were never added to libc. Projects needing them (firecracker, seccompiler, etc.) have been hardcoding the values instead.

Sources

• Linux kernel: https://github.com/torvalds/linux/blob/master/include/uapi/linux/audit.h#L389-L451

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX
• Follows libc patterns: uses 1 << N instead of hex literals for bit shifts
• Tested locally (cargo test -p libc-test --target x86_64-unknown-linux-gnu)

@rustbot label +stable-nominated

[tgross35]

Can you just use https://docs.rs/linux-raw-sys/latest/linux_raw_sys/ptrace/index.html? We're trying to slim down the number of kernel bindings libc has.

[fullzer4]

@tgross35 Thanks for the review and pointing me to linux-raw-sys::ptrace!

After looking at actual usage patterns in the ecosystem, I think there's still a case for keeping them in libc. Let me explain:

Key Points

1. libc already has the seccomp API

libc provides seccomp() syscall and 30 related constants:

• SECCOMP_MODE_*, SECCOMP_SET_MODE_*
• SECCOMP_RET_* (return values)
• SECCOMP_FILTER_FLAG_* (flags)

AUDIT_ARCH_* constants are used primarily for architecture validation in seccomp BPF filters they complete this API.

2. Production projects are hardcoding because they use libc, not linux-raw-sys

rust-vmm/seccompiler (used by Firecracker 35k stars):

src/backend/bpf.rs:119-129:

pub const AUDIT_ARCH_X86_64: u32 = 62 | 0x8000_0000 | 0x4000_0000;
pub const AUDIT_ARCH_AARCH64: u32 = 183 | 0x8000_0000 | 0x4000_0000;
pub const AUDIT_ARCH_RISCV64: u32 = 243 | 0x8000_0000 | 0x4000_0000;

Their dependencies (Cargo.toml):

• libc = "^0.2.153"
• No linux-raw-sys

youki container runtime (7.5k stars) same pattern: hardcodes values, uses libc.

3. Current ecosystem pattern

Projects using AUDIT_ARCH for seccomp (GitHub Code Search):

• rust-vmm/seccompiler → hardcodes, uses libc
• youki → hardcodes, uses libc
• 20+ other projects → similar pattern

The constants exist in linux-raw-sys::ptrace, but they're in the ptrace module while being used for seccomp filters. Projects doing seccomp work already depend on libc for the seccomp() syscall.

Question about libc's direction

I understand the goal to reduce kernel bindings in libc. I'd like to understand the criteria better so I can contribute more effectively in the future:

Should constants that are companions to existing libc APIs be included in libc?

For example:

• libc has seccomp() syscall + 30 SECCOMP_* constants
• AUDIT_ARCH_* constants are used primarily with seccomp BPF filters for architecture validation (seccomp(2) shows AUDIT_ARCH_X86_64 in example code, kernel docs emphasize "always check the arch value")
• They're part of the seccomp workflow, not general audit subsystem constants

Or is the policy to move all kernel-specific constants to linux-raw-sys regardless of their relationship to existing libc APIs?

Understanding this policy would help me (and projects like rust-vmm/seccompiler) make the right architectural decisions. If the direction is "use linux-raw-sys for kernel constants even when tied to libc APIs", that's valuable guidance for future contributions and I can help document that pattern.

What do you think?