linux-kernel - Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core

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: <f52fb3f0-20a4-4b4b-a078-6142c73a4555@nvidia.com>
Date: Tue, 7 Oct 2025 11:00:01 +0000
From: Zhi Wang <zhiw@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
CC: Jason Gunthorpe <jgg@...dia.com>, John Hubbard <jhubbard@...dia.com>,
	Alexandre Courbot <acourbot@...dia.com>, Joel Fernandes
	<joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>, Alistair Popple
	<apopple@...dia.com>, Surath Mitra <smitra@...dia.com>, David Airlie
	<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Bjorn Helgaas
	<bhelgaas@...gle.com>, Krzysztof Wilczyński
	<kwilczynski@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
	<alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
	<gary@...yguo.net>, Björn Roy Baron
	<bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, Andreas
 Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
 Gross <tmgross@...ch.edu>, "nouveau@...ts.freedesktop.org"
	<nouveau@...ts.freedesktop.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Alex
 Williamson <alex.williamson@...hat.com>, Neo Jia <cjia@...dia.com>
Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in
 nova-core

On 7.10.2025 13.14, Danilo Krummrich wrote:
> On Tue Oct 7, 2025 at 8:51 AM CEST, Zhi Wang wrote:
>> From the device vendor’s perspective, we have no support or use case for
>> a bare-metal VF model, not now and not in the foreseeable future.
> 
> Who is we? I think there'd be a ton of users that do see such use-cases.
> 
> What does "no support" mean? Are there technical limitation that prevent an> implementation (I haven't seen any so far)?
> 
>> Even
>> hypothetically, such support would not come from nova-core.ko, since
>> that would defeat the purpose of maintaining a trimmed-down kernel
>> module where minimizing the attack surface and preserving strict
>> security boundaries are primary design goals.
> 
> I wouldn't say the *primary* design goal is to be as trimmed-down as possible.
> 
> The primary design goals are rather proper firmware abstraction, addressing
> design incompatibilities with modern graphics and compute APIs, memory safety
> concerns and general maintainability.
> 
> It does make sense to not run the vGPU use-case on top of all the additional DRM
> stuff that will go into nova-drm, since this is clearly not needed in the vGPU
> use-case. But, it doesn't mean that we have to keep everything out of nova-core
> for this purpose.
> 
> I think the bare-metal VF model is a very interesting use-case and if it is
> technically feasable we should support it. And I think it should be in
> nova-core. The difference between nova-core running on a bare metal VF and
> nova-core running on the same VF in a VM shouldn't be that different anyways,
> no?

@Neo. Can you shed some light here?