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: <20240729142008.GC3371438@nvidia.com>
Date: Mon, 29 Jul 2024 11:20:08 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Jiri Kosina <jikos@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>, ksummit@...ts.linux.dev,
	linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Fri, Jul 26, 2024 at 05:22:17PM +0300, Laurent Pinchart wrote:

> I believe the latter can't be solved technically. At the end of the day
> it's a matter of trust, and the only option I can see is to build that
> trust with the vendors, and to make it clear that breaches of trust will
> have consequences. A vendor that deliberately lies would end up on my
> personal backlist for as long as they don't implement structural
> solutions to be a better player in the ecosystem.

FWIW this is largely my thinking with fwctl as well.

> As for the first issue, I think it's a difficult one as it is very
> difficult to quantify the features covered by open implementations, as
> well as their importance. You could have a 99% open command set where
> the 1% would impact open implementations extremely negatively, the same
> way you could have a 50% open command set where the other 50% isn't of
> any use to anyone but the vendor (for instance used to debug the
> firmware implementation).

I think it is likely cameras, there are lots and lots of use cases and
scenarios. If you focus on a specific use case you need everything for
that case. Another view would be how many scenarios and users does the
open stack cover.

> I'm sorry that this discussion is turning into something very
> camera-centric, but that's the relevant area I know best. I hope that
> discussing problems related to device pass-through in different areas in
> the open will help build a wider shared understanding of the problems,
> and hopefully help designing solutions by better taking into account the
> various aspects of the issues.

To be clear I wouldn't imagine fwctl as relating much to cameras,
maybe you'd use fwctl to get diagnostics out of the camera fw or
something, but it shouldn't touch the image path topics here.

Jason