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: <668d92f68916f_102cc2947b@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 9 Jul 2024 12:43:50 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Christoph Hellwig <hch@...radead.org>, Dan Williams
	<dan.j.williams@...el.com>
CC: <ksummit@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
	<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>, <jgg@...dia.com>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

Christoph Hellwig wrote:
> Passthrough in general is useful, but the problem is that protocols
> aren't designed with it in mind.  Look at the list of command that
> affect too much state and we have to block in SCSI and NVMe.  And
> in NVMe I'm fighting a constant fight in the technical working group
> to not add new command that instantly disable the access control we've
> built into NVMe passthrough.   So IMHO passthrough can be good idea,
> but only if the protocol is designed for it, and protocol designer
> generally have a hard time how software works at all, never mind
> the futuristic concepts of layering, abstraction and access control.
> 

I think this protocol feedback from the kernel community to hardware
designers is top on the list of benefits for this discussion.

How to draw that "needs kernel mediation" line takes
kernel-developer-practitioner expertise.

The positive takeaway from the NVME experience in my mind is that no
doubt the NVME subsystem has blocked commands that hardware developers
prefer that Linux not filter. That filter is likely trivially bypassed
by repurposing some other non-filtered command to have the desired side
effect. Something like "write to a magic LBA == run filtered command".
The fact that those cynical hacks are not deployed and the technical
working group is still holding discussions on the proper protocol means
that hardware designers have a higher incentive to get it right than to
get it deployed.

The conversation seems to break down when it comes to "trust us this
passthrough is only for device-specific functionality with low cross
vendor or kernel appeal." How can we design protocols that have a
high-level of trust?

A "Command Effects Log" seems like that starting point, with trust that
cynical abuses of that contract have a higher cost than benefit, and
trust that the protocol limits the potential damage of such abuse.