netdev - Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

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: <20240801142223.GM3371438@nvidia.com>
Date: Thu, 1 Aug 2024 11:22:23 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: Dan Williams <dan.j.williams@...el.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	ksummit@...ts.linux.dev, linux-cxl@...r.kernel.org,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
	shiju.jose@...wei.com, Borislav Petkov <bp@...en8.de>,
	Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Tue, Jul 30, 2024 at 09:13:00AM +0200, Daniel Vetter wrote:
> I think a solid consensus on the topics above would be really useful for
> gpu/accel too. We're still busy with more pressing community/ecosystem
> building needs, but gpu fw has become rather complex and it's not
> stopping. And there's random other devices attached too nowadays, so fwctl
> makes a ton of sense.

Yeah, I'm pretty sure GPU is going to need fwctl too, the GPU's are
going to have the same issues as NIC does. I see people are already
struggling with topics like how to get debug traces out of the GPU FW.

> But for me the more important stuff would be some clear guidelines like
> what should be in other more across-devices subsystems like edac (or other
> ras features), what should be in functional subsystems like netdev, rdma,
> gpu/accel, ... whatever else, and what should be exposed through some
> special purpose subsystems like hwmon.

In my mind the most important part is that fwctl is not exclusive, the
FW interface and things being manipulated must be sharable or blocked
from fwctl. We should never get in a situation where a fwctl
implementation becomes a reason we cannot have a functional subsystem
interface.

> We've got plenty of experience in enforcing such a community contract with
> vendors, but the hard part is creating a clear and ideally concise
> documentation page I can just point vendors at as the ground truth.

Well, I tried with the documentation in the fwctl patch series..

https://lore.kernel.org/linux-rdma/6-v2-940e479ceba9+3821-fwctl_jgg@nvidia.com/

Jason