February 2021 - Linux-stable-mirror

FAILED: patch "[PATCH] KVM: do not assume PTE is writable after follow_pfn" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Mon, 1 Feb 2021 05:12:11 -0500 Subject: [PATCH] KVM: do not assume PTE is writable after follow_pfn In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens <stevensd(a)google.com> Cc: 3pvd(a)google.com Cc: Jann Horn <jannh(a)google.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8367d88ce39b..335a1a2b8edc 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, kvm_pfn_t *p_pfn) { unsigned long pfn; + pte_t *ptep; + spinlock_t *ptl; int r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) { /* * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does @@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, if (r) return r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) return r; + } + if (write_fault && !pte_write(*ptep)) { + pfn = KVM_PFN_ERR_RO_FAULT; + goto out; } if (writable) - *writable = true; + *writable = pte_write(*ptep); + pfn = pte_pfn(*ptep); /* * Get a reference here because callers of *hva_to_pfn* and @@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, */ kvm_get_pfn(pfn); +out: + pte_unmap_unlock(ptep, ptl); *p_pfn = pfn; return 0; }

3 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] KVM: do not assume PTE is writable after follow_pfn" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Mon, 1 Feb 2021 05:12:11 -0500 Subject: [PATCH] KVM: do not assume PTE is writable after follow_pfn In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens <stevensd(a)google.com> Cc: 3pvd(a)google.com Cc: Jann Horn <jannh(a)google.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8367d88ce39b..335a1a2b8edc 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, kvm_pfn_t *p_pfn) { unsigned long pfn; + pte_t *ptep; + spinlock_t *ptl; int r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) { /* * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does @@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, if (r) return r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) return r; + } + if (write_fault && !pte_write(*ptep)) { + pfn = KVM_PFN_ERR_RO_FAULT; + goto out; } if (writable) - *writable = true; + *writable = pte_write(*ptep); + pfn = pte_pfn(*ptep); /* * Get a reference here because callers of *hva_to_pfn* and @@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, */ kvm_get_pfn(pfn); +out: + pte_unmap_unlock(ptep, ptl); *p_pfn = pfn; return 0; }

3 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] KVM: do not assume PTE is writable after follow_pfn" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Mon, 1 Feb 2021 05:12:11 -0500 Subject: [PATCH] KVM: do not assume PTE is writable after follow_pfn In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens <stevensd(a)google.com> Cc: 3pvd(a)google.com Cc: Jann Horn <jannh(a)google.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8367d88ce39b..335a1a2b8edc 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, kvm_pfn_t *p_pfn) { unsigned long pfn; + pte_t *ptep; + spinlock_t *ptl; int r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) { /* * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does @@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, if (r) return r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) return r; + } + if (write_fault && !pte_write(*ptep)) { + pfn = KVM_PFN_ERR_RO_FAULT; + goto out; } if (writable) - *writable = true; + *writable = pte_write(*ptep); + pfn = pte_pfn(*ptep); /* * Get a reference here because callers of *hva_to_pfn* and @@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, */ kvm_get_pfn(pfn); +out: + pte_unmap_unlock(ptep, ptl); *p_pfn = pfn; return 0; }

3 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] KVM: do not assume PTE is writable after follow_pfn" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Mon, 1 Feb 2021 05:12:11 -0500 Subject: [PATCH] KVM: do not assume PTE is writable after follow_pfn In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens <stevensd(a)google.com> Cc: 3pvd(a)google.com Cc: Jann Horn <jannh(a)google.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8367d88ce39b..335a1a2b8edc 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, kvm_pfn_t *p_pfn) { unsigned long pfn; + pte_t *ptep; + spinlock_t *ptl; int r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) { /* * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does @@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, if (r) return r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) return r; + } + if (write_fault && !pte_write(*ptep)) { + pfn = KVM_PFN_ERR_RO_FAULT; + goto out; } if (writable) - *writable = true; + *writable = pte_write(*ptep); + pfn = pte_pfn(*ptep); /* * Get a reference here because callers of *hva_to_pfn* and @@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, */ kvm_get_pfn(pfn); +out: + pte_unmap_unlock(ptep, ptl); *p_pfn = pfn; return 0; }

3 years, 10 months

1
0
0 0

[PATCH 4.4 00/35] 4.4.258-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.258 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.258-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.258-rc1 Lai Jiangshan <laijs(a)linux.alibaba.com> kvm: check tlbs_dirty directly Arun Easi <aeasi(a)marvell.com> scsi: qla2xxx: Fix crash during driver load on big endian machines Jan Beulich <jbeulich(a)suse.com> xen-blkback: fix error handling in xen_blkbk_map() Jan Beulich <jbeulich(a)suse.com> xen-scsiback: don't "handle" error by BUG() Jan Beulich <jbeulich(a)suse.com> xen-netback: don't "handle" error by BUG() Jan Beulich <jbeulich(a)suse.com> xen-blkback: don't "handle" error by BUG() Stefano Stabellini <stefano.stabellini(a)xilinx.com> xen/arm: don't ignore return errors from set_phys_to_machine Jan Beulich <jbeulich(a)suse.com> Xen/gntdev: correct error checking in gntdev_map_grant_pages() Jan Beulich <jbeulich(a)suse.com> Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages() Jan Beulich <jbeulich(a)suse.com> Xen/x86: also check kernel mapping in set_foreign_p2m_mapping() Jan Beulich <jbeulich(a)suse.com> Xen/x86: don't bail early from clear_foreign_p2m_mapping() Vasily Gorbik <gor(a)linux.ibm.com> tracing: Avoid calling cc-option -mrecord-mcount for every Makefile Greg Thelen <gthelen(a)google.com> tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount Andi Kleen <ak(a)linux.intel.com> trace: Use -mcount-record for dynamic ftrace Borislav Petkov <bp(a)suse.de> x86/build: Disable CET instrumentation in the kernel for 32-bit too Stefano Garzarella <sgarzare(a)redhat.com> vsock: fix locking in vsock_shutdown() Edwin Peer <edwin.peer(a)broadcom.com> net: watchdog: hold device global xmit lock during tx disable Serge Semin <Sergey.Semin(a)baikalelectronics.ru> usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one Felipe Balbi <balbi(a)kernel.org> usb: dwc3: ulpi: fix checkpatch warning Randy Dunlap <rdunlap(a)infradead.org> h8300: fix PREEMPTION build, TI_PRE_COUNT undefined Jozsef Kadlecsik <kadlec(a)mail.kfki.hu> netfilter: xt_recent: Fix attempt to update deleted entry Roman Gushchin <guro(a)fb.com> memblock: do not start bottom-up allocations with kernel_end Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in xattr id lookup Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in inode lookup Phillip Lougher <phillip(a)squashfs.org.uk> squashfs: add more sanity checks in id lookup Theodore Ts'o <tytso(a)mit.edu> memcg: fix a crash in wb_workfn when a device disappears Qian Cai <cai(a)lca.pw> include/trace/events/writeback.h: fix -Wstringop-truncation warnings Tobin C. Harding <tobin(a)kernel.org> lib/string: Add strscpy_pad() function Dave Wysochanski <dwysocha(a)redhat.com> SUNRPC: Handle 0 length opaque XDR object data properly Dave Wysochanski <dwysocha(a)redhat.com> SUNRPC: Move simple_get_bytes and simple_get_netobj into private header Johannes Berg <johannes.berg(a)intel.com> iwlwifi: mvm: guard against device removal in reprobe Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap Cong Wang <cong.wang(a)bytedance.com> af_key: relax availability checks for skb size calculation Steven Rostedt (VMware) <rostedt(a)goodmis.org> fgraph: Initialize tracing_graph_pause at task creation Steven Rostedt (VMware) <rostedt(a)goodmis.org> tracing: Do not count ftrace events in top level enable output ------------- Diffstat: Makefile | 11 +++++- arch/arm/xen/p2m.c | 6 ++- arch/h8300/kernel/asm-offsets.c | 3 ++ arch/x86/Makefile | 6 +-- arch/x86/xen/p2m.c | 15 ++++---- drivers/block/xen-blkback/blkback.c | 28 ++++++++------ drivers/net/wireless/iwlwifi/mvm/ops.c | 3 +- drivers/net/wireless/iwlwifi/pcie/tx.c | 5 +++ drivers/net/xen-netback/netback.c | 4 +- drivers/scsi/qla2xxx/qla_tmpl.c | 9 +++-- drivers/scsi/qla2xxx/qla_tmpl.h | 2 +- drivers/usb/dwc3/ulpi.c | 20 ++++++++-- drivers/xen/gntdev.c | 33 +++++++++++------ drivers/xen/xen-scsiback.c | 4 +- fs/fs-writeback.c | 2 +- fs/squashfs/export.c | 41 ++++++++++++++++---- fs/squashfs/id.c | 40 ++++++++++++++++---- fs/squashfs/squashfs_fs_sb.h | 1 + fs/squashfs/super.c | 6 +-- fs/squashfs/xattr.h | 10 ++++- fs/squashfs/xattr_id.c | 66 ++++++++++++++++++++++++++++----- include/linux/backing-dev.h | 10 +++++ include/linux/ftrace.h | 4 +- include/linux/netdevice.h | 2 + include/linux/string.h | 4 ++ include/linux/sunrpc/xdr.h | 3 +- include/trace/events/writeback.h | 35 +++++++++-------- include/xen/grant_table.h | 1 + kernel/trace/ftrace.c | 2 - kernel/trace/trace_events.c | 3 +- lib/string.c | 47 +++++++++++++++++++---- mm/backing-dev.c | 1 + mm/memblock.c | 49 +++--------------------- net/key/af_key.c | 6 +-- net/netfilter/xt_recent.c | 12 +++++- net/sunrpc/auth_gss/auth_gss.c | 30 +-------------- net/sunrpc/auth_gss/auth_gss_internal.h | 45 ++++++++++++++++++++++ net/sunrpc/auth_gss/gss_krb5_mech.c | 31 +--------------- net/vmw_vsock/af_vsock.c | 8 ++-- scripts/Makefile.build | 3 ++ virt/kvm/kvm_main.c | 3 +- 41 files changed, 389 insertions(+), 225 deletions(-)

3 years, 10 months

7
43
0 0

FAILED: patch "[PATCH] KVM: x86: Set so called 'reserved CR3 bits in LM mask' at" failed to apply to 5.11-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.11-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f156abec725f945f9884bc6a5bd0dccb5aac16a8 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 3 Feb 2021 16:01:06 -0800 Subject: [PATCH] KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU reset. The reserved bits check needs to be done even if userspace never configures the guest's CPUID model. Cc: stable(a)vger.kernel.org Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch") Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210204000117.3303214-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 838ce5e9814b..10414a78b951 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10080,6 +10080,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) fx_init(vcpu); vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu); + vcpu->arch.cr3_lm_rsvd_bits = rsvd_bits(cpuid_maxphyaddr(vcpu), 63); vcpu->arch.pat = MSR_IA32_CR_PAT_DEFAULT;

3 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] KVM: x86: Set so called 'reserved CR3 bits in LM mask' at" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f156abec725f945f9884bc6a5bd0dccb5aac16a8 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 3 Feb 2021 16:01:06 -0800 Subject: [PATCH] KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU reset. The reserved bits check needs to be done even if userspace never configures the guest's CPUID model. Cc: stable(a)vger.kernel.org Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch") Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210204000117.3303214-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 838ce5e9814b..10414a78b951 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10080,6 +10080,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) fx_init(vcpu); vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu); + vcpu->arch.cr3_lm_rsvd_bits = rsvd_bits(cpuid_maxphyaddr(vcpu), 63); vcpu->arch.pat = MSR_IA32_CR_PAT_DEFAULT;

3 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] KVM: do not assume PTE is writable after follow_pfn" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd2fae8da794b55bf2ac02632da3a151b10e664c Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Mon, 1 Feb 2021 05:12:11 -0500 Subject: [PATCH] KVM: do not assume PTE is writable after follow_pfn In order to convert an HVA to a PFN, KVM usually tries to use the get_user_pages family of functinso. This however is not possible for VM_IO vmas; in that case, KVM instead uses follow_pfn. In doing this however KVM loses the information on whether the PFN is writable. That is usually not a problem because the main use of VM_IO vmas with KVM is for BARs in PCI device assignment, however it is a bug. To fix it, use follow_pte and check pte_write while under the protection of the PTE lock. The information can be used to fail hva_to_pfn_remapped or passed back to the caller via *writable. Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05); however, even older version have the same issue, all the way back to commit 2e2e3738af33 ("KVM: Handle vma regions with no backing page", 2008-07-20), as they also did not check whether the PFN was writable. Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page") Reported-by: David Stevens <stevensd(a)google.com> Cc: 3pvd(a)google.com Cc: Jann Horn <jannh(a)google.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8367d88ce39b..335a1a2b8edc 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1904,9 +1904,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, kvm_pfn_t *p_pfn) { unsigned long pfn; + pte_t *ptep; + spinlock_t *ptl; int r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) { /* * get_user_pages fails for VM_IO and VM_PFNMAP vmas and does @@ -1921,14 +1923,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, if (r) return r; - r = follow_pfn(vma, addr, &pfn); + r = follow_pte(vma->vm_mm, addr, NULL, &ptep, NULL, &ptl); if (r) return r; + } + if (write_fault && !pte_write(*ptep)) { + pfn = KVM_PFN_ERR_RO_FAULT; + goto out; } if (writable) - *writable = true; + *writable = pte_write(*ptep); + pfn = pte_pfn(*ptep); /* * Get a reference here because callers of *hva_to_pfn* and @@ -1943,6 +1950,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, */ kvm_get_pfn(pfn); +out: + pte_unmap_unlock(ptep, ptl); *p_pfn = pfn; return 0; }

3 years, 10 months

1
0
0 0

[5.4 / 4.19] backport of 2cea4a7a1885bd0c765089afc14f7ff0eb77864e and fe968c41ac4f4ec9ffe3c4cf16b72285f5e9674f

by Rolf Eike Beer

Hi, the attached patches are the backport of these 2 patches for tools/Makefile that allows building when OpenSSL is not at the default location. They apply cleanly to both to 5.4.99 and 4.19.176. Backports for older stable kernels will follow. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source

3 years, 10 months

2
3
0 0

Re: [linux-stable-rc:linux-5.4.y 2231/4843] ERROR: "__memcat_p" undefined!

by Nick Desaulniers

On Mon, Feb 15, 2021 at 2:49 AM kernel test robot <lkp(a)intel.com> wrote: > > Hi Nick, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y > head: 642aa3284e09f63bf1d4832798dd787b4320ca64 > commit: f05f667f8764f9ec834ca3e412ed7f5a20dea3bf [2231/4843] lib/string.c: implement stpcpy > config: x86_64-randconfig-a005-20210215 (attached as .config) > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install x86_64 cross compiling tool for clang build > # apt-get install binutils-x86-64-linux-gnu > # https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/… > git remote add linux-stable-rc https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git fetch --no-tags linux-stable-rc linux-5.4.y > git checkout f05f667f8764f9ec834ca3e412ed7f5a20dea3bf > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp(a)intel.com> > > All errors (new ones prefixed by >>): > > >> ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined! This error is unrelated to the referenced commit, but we did fix this error finally in 5.7: https://github.com/ClangBuiltLinux/linux/issues/515. This is not a regression, but something that never worked with LLD until 5.7. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… looks like the commit of interest, though I seem to have left a comment implying there were dependencies: https://github.com/ClangBuiltLinux/linux/issues/515#issuecomment-612999929 (I no longer recall what they were). Some other commits in tree reference that bug from the issue tracker. https://github.com/0day-ci/linux/commit/0cf9baa2dbb8ca29f30ac8a1afb69de51f2… https://github.com/0day-ci/linux/commit/565508bb949dd72638b52522fb6ac6ec04e… https://github.com/0day-ci/linux/commit/0d0537aa772566473bd5310be3874060cbf… Not sure whether all 4 of the above worth backporting to 4.4.y? Thoughts? (Perhaps these would allow us to add x86_64 allmodconfig CI coverage with LLD for 4.4.y) > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org -- Thanks, ~Nick Desaulniers

3 years, 10 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021