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: <DDC0EQ0793TC.2W132ZB3J9LPK@kernel.org>
Date: Tue, 07 Oct 2025 12:14:42 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Zhi Wang" <zhiw@...dia.com>
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 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?