Hi, Dave, On 10/12/22 14:14, Dave Hansen wrote: > On 10/12/22 13:14, Fenghua Yu wrote: > > Userspace can directly access physical address through user type Work > > Queue (WQ) in two scenarios: no IOMMU or IOMMU Passthrough without > > Shared Virtual Addressing (SVA). In these two cases, user type WQ > > allows userspace to issue DMA physical address access without virtual > > to physical translation. > > > > This is inconsistent with the security goals of a good kernel API. > > > > Plus there is no usage for user type WQ without SVA. > > > > So enable user type WQ only when SVA is enabled (i.e. user PASID is > > enabled). > > I'm not sure the changelog here is great. > > The whole "user Work Queue" thing is an entire *DRIVER*. So, this really has > zero to do with the type of workqueue and everything to do with the kind of > drivers we allow to be loaded and drive the hardware. > > Basically, the *hardware* allows pretty arbitrary direct access to physical > memory. The 'idxd_user_drv' driver code (including > idxd_user_drv_probe()) gives low-level, direct access to the hardware, which is > bad news. > > Plus, even if userspace got access to the device via this driver, they have to feel > physical addresses to it, which is generally not easy from userspace. > > That's as close as I can get to rephrasing the above TLA soup in plain old English. > > I also detest the "There is no usage case for the WQ without SVA." > language. Those words lack meaning. There has to be a *REASON* there is no > use case. Please think about what those words *mean*, then delete them and > write what they mean. I'm working on changing the changelog and will send v2 with the changes. Thanks. -Fenghua
