On Tue, Oct 19, 2021 at 09:22:13AM +0800, Jason Wang wrote: > > > So I think clarifying system reset should address your questions. > > > I believe we should leave bypass sticky across device reset, so a FW->OS > > > transition, where the OS resets the device, does not open a vulnerability > > > (if bypass was enabled at boot and then left disabled by FW.) > > > > > > It's still a good idea for the OS to restore on shutdown the bypass value > > > it was booted with. So it can kexec into an OS that doesn't support > > > virtio-iommu, for example. > > > > > > Thanks, > > > Jean > > > > Is this stickiness really important? It is important when FW has to hand the IOMMU over to the OS while keeping DMA disabled for all endpoints. For example DMA was globally disabled on boot through some external mechanism (e.g. Bus Master Enable in PCI bridges), and FW disables IOMMU bypass before enabling Bus Master, and there are some untrusted endpoints in the system that should never be allowed to perform arbitrary DMA. If a side effect of resetting the IOMMU is to enable bypass, then the OS opens a vulnerability without knowing it. That's a real problem on hardware platforms, but maybe too far fetched on virtual ones. > > Can't this be addressed just by hypervisor disabling bypass at boot? Yes I suppose we have that option. If we make bypass non-sticky, we're preventing FW from working around vulnerable device implementations, but fixing the implementation itself is much easier in virtualization than in hardware. > And I'm not sure if sticky can survive transport reset. I thought "device reset" includes transport reset as well? There seems to be a precedent with virtio-mem which keeps state across device reset. And PCI allows sticky registers across FLR (RWS registers) Thanks, Jean _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
