linux-kernel - Re: [RFC PATCH v3 3/5] rust: io_uring: introduce rust abstraction for io-uring cmd

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: <DCDVQJI16SQI.RKEIM4BE7RZT@kernel.org>
Date: Thu, 28 Aug 2025 09:24:24 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>, "Sidong Yang"
 <sidong.yang@...iosa.ai>
Cc: "Jens Axboe" <axboe@...nel.dk>, "Caleb Sander Mateos"
 <csander@...estorage.com>, "Miguel Ojeda" <ojeda@...nel.org>, "Arnd
 Bergmann" <arnd@...db.de>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <io-uring@...r.kernel.org>
Subject: Re: [RFC PATCH v3 3/5] rust: io_uring: introduce rust abstraction
 for io-uring cmd

On Wed Aug 27, 2025 at 10:41 PM CEST, Daniel Almeida wrote:
>> On 22 Aug 2025, at 09:55, Sidong Yang <sidong.yang@...iosa.ai> wrote:
>> +        }
>> +
>> +        let mut out: MaybeUninit<T> = MaybeUninit::uninit();
>> +        let ptr = &raw mut inner.pdu as *const c_void;
>> +
>> +        // SAFETY:
>> +        // * The `ptr` is valid pointer from `self.inner` that is guaranteed by type invariant.
>> +        // * The `out` is valid pointer that points `T` which impls `FromBytes` and checked
>> +        //   size of `T` is smaller than pdu size.
>> +        unsafe {
>> +            core::ptr::copy_nonoverlapping(ptr, out.as_mut_ptr().cast::<c_void>(), len);
>
> I don’t think you need to manually specify c_void here.

In fact using `c_void` as the pointee type is wrong, since it's a ZST
and thus this call copies no bytes whatsoever.

> Benno, can’t we use core::mem::zeroed() or something like that to avoid this unsafe?
>
> The input was zeroed in prep() and the output can just be a zeroed T on the
> stack, unless I missed something?

Hmm I'm not sure I follow, I don't think that `mem::zeroed` will help
(it also is an unsafe function).

We have a helper in flight that might be useful in this case:

    https://lore.kernel.org/all/20250826-nova_firmware-v2-1-93566252fe3a@nvidia.com

---
Cheers,
Benno