linux-kernel - Re: [RFC 0/2] rust: introduce abstractions for fwctl

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: <DDVUJRUAMI4T.1OLCH55GSGYCM@kernel.org>
Date: Thu, 30 Oct 2025 18:52:31 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Zhi Wang" <zhiw@...dia.com>
Cc: "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
 "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "kwilczynski@...nel.org"
 <kwilczynski@...nel.org>, "ojeda@...nel.org" <ojeda@...nel.org>,
 "alex.gaynor@...il.com" <alex.gaynor@...il.com>, "boqun.feng@...il.com"
 <boqun.feng@...il.com>, "gary@...yguo.net" <gary@...yguo.net>,
 "bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>, "lossin@...nel.org"
 <lossin@...nel.org>, "a.hindborg@...nel.org" <a.hindborg@...nel.org>,
 "aliceryhl@...gle.com" <aliceryhl@...gle.com>, "tmgross@...ch.edu"
 <tmgross@...ch.edu>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "Neo Jia" <cjia@...dia.com>, "Surath Mitra"
 <smitra@...dia.com>, "Ankit Agrawal" <ankita@...dia.com>, "Aniket Agashe"
 <aniketa@...dia.com>, "Kirti Wankhede" <kwankhede@...dia.com>, "Tarun Gupta
 (SW-GPU)" <targupta@...dia.com>, "zhiwang@...nel.org" <zhiwang@...nel.org>,
 "Alex Williamson" <alwilliamson@...dia.com>, "Alexandre Courbot"
 <acourbot@...dia.com>, "Joel Fernandes" <joelagnelf@...dia.com>, "John
 Hubbard" <jhubbard@...dia.com>, "Jason Gunthorpe" <jgg@...dia.com>
Subject: Re: [RFC 0/2] rust: introduce abstractions for fwctl

On Thu Oct 30, 2025 at 6:29 PM CET, Zhi Wang wrote:
> On 30.10.2025 18.03, Zhi Wang wrote:
>> In the NVIDIA vGPU RFC [1], the vGPU type blobs must be provided to the GSP
>> before userspace can enumerate available vGPU types and create vGPU
>> instances. The original design relied on the firmware loading interface,
>> but fwctl is a more natural fit for this use case, as it is designed for
>> uploading configuration or firmware data required before the device becomes
>> operational.
>> 
>
> Hi Jason and Danilo:
>
> Thanks for the comments. I had one more open to discuss, handling the buffer
> allocation/free between rust and C world.
>
> Two fwctl ioctls:
>
> FWCTL_CMD_INFO: The driver allocates the info memory (kmalloc) and the fwctl
> subsystem frees it.
>
> FWCTL_RPC:
>
> Case 1: The driver can choose to re-use the input buffer and write the *out_len
> for actual length of data.
>
> Case 2: The driver can allocate a new buffer (kmalloc) and the fwctl subsystem
> frees it.
>
> ----
> Now with the Rust driver:
>
> FWCTL_CMD_INFO: The rust side returns a new KVec, the rust fwctl abstraction
> consumes it, get void *buf and pass it to fwctl subsystem (C). The memory
> will be freed by C side.
>
> FWCTL_RPC:
>
> The input buffer will be wrapped in a mutable slice.
>
> Case 1: Re-use the input buffer. The rust side writes the mut slice and the
> * mut out_len.
>
> Case 2: Allocate the new output buffer. The same approach as FWCTL_CMD_INFO.
>
> ----
>
> We know KVec is backed by kmalloc. If C side changes the requirements of
> the driver memory allocation someday, E.g. from kfree() to kvfree() or vfree().
>
> Drivers in C will be updated surely at that time.
>
> Is possible that we can have some approaches to catch that change from the rust
> side via rust compiler for rust drivers?

I don't think we have the possibility of doing any compile time check here,
since on the C side the type is always void * for any memory allocation.

However, I think the only broken case would be if C switches to vmalloc() (and
hence vfree()), but the Rust code doesn't. That sounds unlikely to me for three
reasons.

  (1) I think if there'd be a change it would be to kvmalloc() and calling
      kvfree() on a kmalloc() buffer should be fine.

  (2) A breaking change would also affect all C drivers, so it'd not only be the
      Rust code being affected.