> From: Tian, Kevin > Sent: Friday, May 13, 2016 10:33 AM > > > means. The MSI-X vector table of a device is always considered > > untrusted which is why we require user opt-ins to subvert that > > protection. Thanks, > > > > I only partially agree with this statement since there is different > trust level for kernel space driver and user space driver. > > OS may choose to trust kernel space driver then it can enable IRQ > remapping only for load balance purpose w/o source id verfification. > In such case MSI-X vector table is trusted and fully under kernel > control. Allowing to mmap MSI-X table in user space definitely > breaks that boundary. > > Anyway my point is simple. Let's ignore how Linux kernel implements > IRQ remapping on x86 (which may change time to time), and just > focus on architectural possibility. Non-x86 platform may implement > IRQ remapping completely separate from device side, then checking > availability of IRQ remapping is enough to decide whether mmap > MSI-X table is safe. x86 with VT-d can be configured to a mode > requiring host control of both MSI-X entry and IRQ remapping hardware > (without source id check). In such case it's insufficient to make > decision simply based on IRQ remapping availability. We need a way > to query from IRQ remapping module whether it's actually safe to > mmap MSI-X. > Or another way is to have VFIO explicitly request intel-iommu to enforce sid check when IRQ remapping is enabled... Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
