On Fri, 29 Jun 2018 11:55:40 +1000 Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote: > Alexey Kardashevskiy <aik@xxxxxxxxx> writes: > > > This is to improve page boundaries checking and should probably > > be cc:stable. I came accross this while debugging nvlink2 passthrough > > but the lack of checking might be exploited by the existing userspace. > > Do you really mean "exploited" ? As in there's a security issue? > > Your change log for patch 2 sort of suggests that but then says that > without the fix you just hit an error in vfio code. The bug is that I can easily make unmodified guest use 16MB IOMMU pages while guest RAM is backed with system 64K pages so unless the guest RAM is allocated contigously (which is unlikely), a 16MB TCE will provide the hardware access to the host physical memory it is not supposed to have access to, which is 16MB minus first 64K. There is a fast path for H_PUT_TCE - via KVM - there is no contained test. There is a slow path for H_PUT_TCE - via VFIO ioctl() - there is a contained test. Because of a different feature of VFIO on sPAPR (it stores an array of userspace addresses which we received from QEMU and translated to host physical addresses and programmed those to the TCE table) we do not take the fast path on the very first H_PUT_TCE (because I allocate the array when the slow path is taken the very first time), fail there, pass the failure to the guest the guest decides that is over. But a modified guest could ignore that initial H_PUT_TCE failure and simply repeat H_PUT_TCE again - this time it will take the fast path and allow the bad mapping. > So I'm not clear on what the exposure is. > > cheers -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
