Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp205420ybl; Thu, 5 Dec 2019 18:09:55 -0800 (PST) X-Google-Smtp-Source: APXvYqzykLRw1erpDkwTJADIrFZOazWneA9b6x11W7kkIkBPZajjskWYtzH0C2DTgEnvFUDCnNQl X-Received: by 2002:a05:6830:1185:: with SMTP id u5mr8813118otq.147.1575598195051; Thu, 05 Dec 2019 18:09:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575598195; cv=none; d=google.com; s=arc-20160816; b=wKRkae53w6JHw/Ey+vNjG9gM51m3KY/vJ8Kw4yR0yEWjrZDswW0Cw5TfJHbgLTJBcE qRfhMZkn7sfHWd7NNXu1CEZB/3YvoutXsyiNFTkcnEMqcz5+MB136uTy8zhHvcomM/Ei YuEBNYv5qFqfywhbkedskplhuDedACV1DEV1qlqwx+QEdx+SBWywwhaey8qzero5lwpP TLHoWIjN4b9CUZdCjDxq0BoUtFdOILWzRuoUHP7yUxJD4yvS4a7mDfTM1dW6vp8Tgf2j gvBOkxjk0rlcUVY4yzMqlz4lIRlCGSx9aTqsL1A8D7PuQHz9QgZubZoaQk8n/5DiHUhp ZwsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=Maa/7nb5sn4McZDaHB7UEa+hipS9AwkJTbGxws6lkXc=; b=psfaRdtCr323QoBfDlunZPk1xfItE/4dDTliYas5A1U3Mn2l6Hv7ykM0aILT5HcFqi t+wprdi6+TiEGC/nQTUM/1bDAWPaR2i/Bc1gwz3RWi4gBqYANUDpPovEGuYHB0QeHthq VwLFYt1cmVfvO95ps7uv+cowzuVkG9+EfkTwEIV1DAhj/aSsVZFspyE7Cc5UBAEBHn2I JNiD/3YBcCEoeEeJE9PFtLY0YuNgthTRossleAYsuboo6vtuPcHSiUsGRpTW2dr9/ksI x2ZGFHJ/bvbHB47xHyXSrOM3USKUwLv2w1SRi521x/dW4yxv3h5SpQfMr2ROMeSkbVmc HprA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7si6129209otg.238.2019.12.05.18.09.41; Thu, 05 Dec 2019 18:09:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726134AbfLFCI0 (ORCPT + 99 others); Thu, 5 Dec 2019 21:08:26 -0500 Received: from foss.arm.com ([217.140.110.172]:55216 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbfLFCI0 (ORCPT ); Thu, 5 Dec 2019 21:08:26 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4448A31B; Thu, 5 Dec 2019 18:08:20 -0800 (PST) Received: from localhost.localdomain (unknown [10.169.40.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 834003F718; Thu, 5 Dec 2019 18:08:16 -0800 (PST) From: Jia He To: Marc Zyngier , James Morse , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu Cc: Julien Thierry , Suzuki K Poulose , linux-kernel@vger.kernel.org, Jia He , Ard Biesheuvel Subject: [PATCH] KVM: arm: remove excessive permission check in kvm_arch_prepare_memory_region Date: Fri, 6 Dec 2019 10:08:02 +0800 Message-Id: <20191206020802.196108-1-justin.he@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Suggested-by: Ard Biesheuvel Signed-off-by: Jia He --- 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