linux-kernel - Re: Rust kernel policy

lists.openwall.net		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]

Message-ID: <9B01858A-7EBD-4570-AC51-3F66B2B1E868@zytor.com>
Date: Thu, 20 Feb 2025 05:23:54 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Greg KH <gregkh@...uxfoundation.org>, Jan Engelhardt <ej@...i.de>
CC: Boqun Feng <boqun.feng@...il.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Christoph Hellwig <hch@...radead.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
        ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On February 20, 2025 4:37:46 AM PST, Greg KH <gregkh@...uxfoundation.org> wrote:
>On Thu, Feb 20, 2025 at 01:28:58PM +0100, Jan Engelhardt wrote:
>> 
>> On Wednesday 2025-02-19 06:39, Greg KH wrote:
>> >
>> >The majority of bugs (quantity, not quality/severity) we have are due to
>> >the stupid little corner cases in C that are totally gone in Rust.
>> 
>> If and when Rust receives its own corner cases in the future,
>> I will happily point back to this statement.
>
>I'm not saying that rust has no such issues, I'm saying that a huge
>majority of the stupid things we do in C just don't happen in the same
>code implemented in rust (i.e. memory leaks, error path cleanups, return
>value checking, etc.)
>
>So sure, let's make different types of errors in the future, not
>continue to make the same ones we should have learned from already
>please :)
>
>thanks,
>
>greg k-h
>

I would like to point out that quite frankly we have been using a C style which is extremely traditional, but which have been known to cause problems many times; specifically, using *alloc, memcpy() and memset() with explicit sizes; migrating towards using sizeof() but still having to type it explicitly, and the known confusion of sizeof(ptr) and sizeof(*ptr). This could and probably should be macroized to avoid the redundancy.

In the NASM codebase I long ago started using nasm_new() and nasm_zero() macros for this purpose, and structure copies really can just be aasignment statements. People writing C seem to have a real aversion for using structures as values (arguments, return values or assignments) even though that has been valid since at least C90 and can genuinely produce better code in some cases.