On Thu, Oct 03, 2024 at 03:00:21PM -0700, Bart Van Assche wrote: > On 10/3/24 2:48 PM, Keith Busch wrote: > > The only "bonus" I have is not repeatedly explaining why people can't > > use h/w features the way they want. > > Hi Keith, > > Although that's a fair argument, what are the use cases for this patch > series? Filesystems in the kernel? Filesystems implemented in user > space? Perhaps something else? > > This patch series adds new a new user space interface for passing hints > to storage devices (in io_uring). As we all know such interfaces are > hard to remove once these have been added. > > We don't need new user space interfaces to support FDP for filesystems > in the kernel. > > For filesystems implemented in user space, would using NVMe pass-through > be a viable approach? With this approach, no new user space interfaces > have to be added. > > I'm wondering how to unblock FDP users without adding a new > controversial mechanism in the kernel. I really like the passthrough interface. This is flexible and enables experimenting with all sorts of features. But it exposes exploits and pitfalls. Just check the CVE's against it (ex: CVE-2023-6238, note: same problem exists without metadata). The consequences of misuse include memory corruption and private memory leakage. The barriers for exploits are too low, and the potential for mistakes are too high. A possible h/w solution requires an IOMMU, but that's a non-starter for many users and only solves the private memory vulnerabilities. Passthrough also skips all the block layer features. I just today added statistics to it staged for 6.13, but even that requires yet another config step to enable it. tl;dr: no one wants to use nvme passthrough in production long term.
