lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Oct 2023 13:59:58 +0200
From: Miguel Ojeda <>
To: FUJITA Tomonori <>
Subject: Re: [PATCH net-next v3 1/3] rust: core abstractions for network PHY drivers

On Fri, Oct 13, 2023 at 11:53 AM FUJITA Tomonori
<> wrote:
> I'm not sure the general rules in Rust can be applied to linux kernel.

Benno and others already replied nicely to this, but I wanted to point
out that this happens with C compilers just the same. It is not a
"Rust thing" and what matters is what compilers do here, in practice.

For instance, you can try to compile this with GCC under -O2, and you
will get a program that returns a 2:

    int main(void) {
        _Bool b;
        char c = 42;
        memcpy(&b, &c, 1);
        if (b)
            return 43;
        return 44;

Similarly, one for Rust where LLVM simply generates `ud2`:

    pub enum E {
        A = 0,
        B = 1,

    pub fn main() {
        let e = unsafe { core::mem::transmute::<u32, E>(5) };
        std::process::exit(match e {
            E::A => 42,
            E::B => 43,

The `e` variable is what we can get from C without an unsafe block if
you use `--rustified-enum`, i.e. the case in your abstractions.

The critical bit here is that, in C, it is not UB to have value 5 in
its enum, so we cannot rely on that.


Powered by blists - more mailing lists