Message ID | 20191206020802.196108-1-justin.he@arm.com (mailing list archive) |
---|---|
State | Mainlined |
Commit | 97418e968b01ba8e3ad41c38b42106c48bc19544 |
Headers | show |
Series | KVM: arm: remove excessive permission check in kvm_arch_prepare_memory_region | expand |
On Fri, Dec 06, 2019 at 10:08:02AM +0800, Jia He wrote: > In kvm_arch_prepare_memory_region, arm kvm regards the memory region as > writable if the flag has no KVM_MEM_READONLY, and the vm is readonly if > !VM_WRITE. > > But there is common usage for setting kvm memory region as follows: > e.g. qemu side (see the PROT_NONE flag) > 1. mmap(NULL, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > memory_region_init_ram_ptr() > 2. re mmap the above area with read/write authority. > > Such example is used in virtio-fs qemu codes which hasn't been upstreamed > [1]. But seems we can't forbid this example. > > Without this patch, it will cause an EPERM during kvm_set_memory_region() > and cause qemu boot crash. > > As told by Ard, "the underlying assumption is incorrect, i.e., that the > value of vm_flags at this point in time defines how the VMA is used > during its lifetime. There may be other cases where a VMA is created > with VM_READ vm_flags that are changed to VM_READ|VM_WRITE later, and > we are currently rejecting this use case as well." > > [1] https://gitlab.com/virtio-fs/qemu/blob/5a356e/hw/virtio/vhost-user-fs.c#L488 Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Signed-off-by: Jia He <justin.he@arm.com> > --- > virt/kvm/arm/mmu.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c > index 38b4c910b6c3..a48994af70b8 100644 > --- a/virt/kvm/arm/mmu.c > +++ b/virt/kvm/arm/mmu.c > @@ -2301,15 +2301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, > if (!vma || vma->vm_start >= reg_end) > break; > > - /* > - * Mapping a read-only VMA is only allowed if the > - * memory region is configured as read-only. > - */ > - if (writable && !(vma->vm_flags & VM_WRITE)) { > - ret = -EPERM; > - break; > - } > - > /* > * Take the intersection of this VMA with the memory region > */ > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2019-12-06 02:08, Jia He wrote: > In kvm_arch_prepare_memory_region, arm kvm regards the memory region > as > writable if the flag has no KVM_MEM_READONLY, and the vm is readonly > if > !VM_WRITE. > > But there is common usage for setting kvm memory region as follows: > e.g. qemu side (see the PROT_NONE flag) > 1. mmap(NULL, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > memory_region_init_ram_ptr() > 2. re mmap the above area with read/write authority. > > Such example is used in virtio-fs qemu codes which hasn't been > upstreamed > [1]. But seems we can't forbid this example. > > Without this patch, it will cause an EPERM during > kvm_set_memory_region() > and cause qemu boot crash. > > As told by Ard, "the underlying assumption is incorrect, i.e., that > the > value of vm_flags at this point in time defines how the VMA is used > during its lifetime. There may be other cases where a VMA is created > with VM_READ vm_flags that are changed to VM_READ|VM_WRITE later, and > we are currently rejecting this use case as well." > > [1] > > https://gitlab.com/virtio-fs/qemu/blob/5a356e/hw/virtio/vhost-user-fs.c#L488 > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Signed-off-by: Jia He <justin.he@arm.com> > --- > virt/kvm/arm/mmu.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c > index 38b4c910b6c3..a48994af70b8 100644 > --- a/virt/kvm/arm/mmu.c > +++ b/virt/kvm/arm/mmu.c > @@ -2301,15 +2301,6 @@ int kvm_arch_prepare_memory_region(struct kvm > *kvm, > if (!vma || vma->vm_start >= reg_end) > break; > > - /* > - * Mapping a read-only VMA is only allowed if the > - * memory region is configured as read-only. > - */ > - if (writable && !(vma->vm_flags & VM_WRITE)) { > - ret = -EPERM; > - break; > - } > - > /* > * Take the intersection of this VMA with the memory region > */ Applied, thanks. M.
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c index 38b4c910b6c3..a48994af70b8 100644 --- a/virt/kvm/arm/mmu.c +++ b/virt/kvm/arm/mmu.c @@ -2301,15 +2301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm, if (!vma || vma->vm_start >= reg_end) break; - /* - * Mapping a read-only VMA is only allowed if the - * memory region is configured as read-only. - */ - if (writable && !(vma->vm_flags & VM_WRITE)) { - ret = -EPERM; - break; - } - /* * Take the intersection of this VMA with the memory region */
In kvm_arch_prepare_memory_region, arm kvm regards the memory region as writable if the flag has no KVM_MEM_READONLY, and the vm is readonly if !VM_WRITE. But there is common usage for setting kvm memory region as follows: e.g. qemu side (see the PROT_NONE flag) 1. mmap(NULL, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); memory_region_init_ram_ptr() 2. re mmap the above area with read/write authority. Such example is used in virtio-fs qemu codes which hasn't been upstreamed [1]. But seems we can't forbid this example. Without this patch, it will cause an EPERM during kvm_set_memory_region() and cause qemu boot crash. As told by Ard, "the underlying assumption is incorrect, i.e., that the value of vm_flags at this point in time defines how the VMA is used during its lifetime. There may be other cases where a VMA is created with VM_READ vm_flags that are changed to VM_READ|VM_WRITE later, and we are currently rejecting this use case as well." [1] https://gitlab.com/virtio-fs/qemu/blob/5a356e/hw/virtio/vhost-user-fs.c#L488 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jia He <justin.he@arm.com> --- virt/kvm/arm/mmu.c | 9 --------- 1 file changed, 9 deletions(-)