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.
