linux-toradex.git/virt, branch v2.6.34.15

KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

2014-02-10T21:11:13+00:00

commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream.

If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
that request.  ioapic_read_indirect contains an
ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
non-debug builds.  In recent kernels this allows a guest to cause a kernel
oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
guest to read from large ranges of host memory.

Tested: tested against apic unit tests.

Signed-off-by: Andrew Honig 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Paul Gortmaker

KVM: lock slots_lock around device assignment

2014-02-10T21:10:43+00:00

commit 21a1416a1c945c5aeaeaf791b63c64926018eb77 upstream.

As pointed out by Jason Baron, when assigning a device to a guest
we first set the iommu domain pointer, which enables mapping
and unmapping of memory slots to the iommu.  This leaves a window
where this path is enabled, but we haven't synchronized the iommu
mappings to the existing memory slots.  Thus a slot being removed
at that point could send us down unexpected code paths removing
non-existent pinnings and iommu mappings.  Take the slots_lock
around creating the iommu domain and initial mappings as well as
around iommu teardown to avoid this race.

Signed-off-by: Alex Williamson 
Signed-off-by: Marcelo Tosatti 
[PG: drop goto for EPERM check, 2.6.34 doesn't have that code]
Signed-off-by: Paul Gortmaker

KVM: unmap pages from the iommu when slots are removed

2014-02-10T21:10:42+00:00

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown.  A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.

Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa.  This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.

Signed-off-by: Alex Williamson 
Signed-off-by: Marcelo Tosatti 
[PG: minor tweak since 2.6.34 doesnt have kvm_for_each_memslot]
Signed-off-by: Paul Gortmaker

KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

2012-08-17T19:35:04+00:00

commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream.

If some vcpus are created before KVM_CREATE_IRQCHIP, then
irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
to potential NULL pointer dereferences.

Fix by:
- ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
- ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP

This is somewhat long winded because vcpu->arch.apic is created without
kvm->lock held.

Based on earlier patch by Michael Ellerman.

Signed-off-by: Michael Ellerman 
Signed-off-by: Avi Kivity 
[PG: in .34 label "unlock_vcpu_destroy" is just "vcpu_destroy"]
Signed-off-by: Paul Gortmaker

KVM: Device assignment permission checks

2012-08-17T19:35:04+00:00

commit 3d27e23b17010c668db311140b17bbbb70c78fb9 upstream.

Only allow KVM device assignment to attach to devices which:

 - Are not bridges
 - Have BAR resources (assume others are special devices)
 - The user has permissions to use

Assigning a bridge is a configuration error, it's not supported, and
typically doesn't result in the behavior the user is expecting anyway.
Devices without BAR resources are typically chipset components that
also don't have host drivers.  We don't want users to hold such devices
captive or cause system problems by fencing them off into an iommu
domain.  We determine "permission to use" by testing whether the user
has access to the PCI sysfs resource files.  By default a normal user
will not have access to these files, so it provides a good indication
that an administration agent has granted the user access to the device.

[Yang Bai: add missing #include]
[avi: fix comment style]

Signed-off-by: Alex Williamson 
Signed-off-by: Yang Bai 
Signed-off-by: Marcelo Tosatti 
[PG: Drop Documentation api.txt chunk; 2.6.34 doesn't have the file]
Signed-off-by: Paul Gortmaker

KVM: Remove ability to assign a device without iommu support

2012-08-17T19:35:03+00:00

commit 423873736b78f549fbfa2f715f2e4de7e6c5e1e9 upstream.

This option has no users and it exposes a security hole that we
can allow devices to be assigned without iommu protection.  Make
KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.

Signed-off-by: Alex Williamson 
Signed-off-by: Marcelo Tosatti 
[PG: drop Documentation chunk; no api.txt file in .34 baseline]
Signed-off-by: Paul Gortmaker

KVM: read apic->irr with ioapic lock held

2010-08-02T17:30:06+00:00

Read ioapic->irr inside ioapic->lock protected section.

KVM-Stable-Tag
Signed-off-by: Marcelo Tosatti 
(cherry picked from commit 07dc7263b99e4ddad2b4c69765a428ccb7d48938)

KVM: convert ioapic lock to spinlock

2010-05-13T04:23:55+00:00

kvm_set_irq is used from non sleepable contexes, so convert ioapic from
mutex to spinlock.

KVM-Stable-Tag.
Tested-by: Ralf Bonenkamp 
Signed-off-by: Marcelo Tosatti

KVM: Add missing srcu_read_lock() for kvm_mmu_notifier_release()

2010-04-21T08:17:43+00:00

I got this dmesg due to srcu_read_lock() is missing in
kvm_mmu_notifier_release().

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
arch/x86/kvm/x86.h:72 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
2 locks held by qemu-system-x86/3100:
 #0:  (rcu_read_lock){.+.+..}, at: [] __mmu_notifier_release+0x38/0xdf
 #1:  (&(&kvm->mmu_lock)->rlock){+.+...}, at: [] kvm_mmu_zap_all+0x21/0x5e [kvm]

stack backtrace:
Pid: 3100, comm: qemu-system-x86 Not tainted 2.6.34-rc3-22949-gbc8a97a-dirty #2
Call Trace:
 [] lockdep_rcu_dereference+0xaa/0xb3
 [] unalias_gfn+0x56/0xab [kvm]
 [] gfn_to_memslot+0x16/0x25 [kvm]
 [] gfn_to_rmap+0x17/0x6e [kvm]
 [] rmap_remove+0xa0/0x19d [kvm]
 [] kvm_mmu_zap_page+0x109/0x34d [kvm]
 [] kvm_mmu_zap_all+0x35/0x5e [kvm]
 [] kvm_arch_flush_shadow+0x16/0x22 [kvm]
 [] kvm_mmu_notifier_release+0x15/0x17 [kvm]
 [] __mmu_notifier_release+0x88/0xdf
 [] ? __mmu_notifier_release+0x38/0xdf
 [] ? exit_mm+0xe0/0x115
 [] exit_mmap+0x2c/0x17e
 [] mmput+0x2d/0xd4
 [] exit_mm+0x108/0x115
[...]

Signed-off-by: Lai Jiangshan 
Signed-off-by: Avi Kivity

KVM: fix the handling of dirty bitmaps to avoid overflows

2010-04-20T10:06:55+00:00

Int is not long enough to store the size of a dirty bitmap.

This patch fixes this problem with the introduction of a wrapper
function to calculate the sizes of dirty bitmaps.

Note: in mark_page_dirty(), we have to consider the fact that
  __set_bit() takes the offset as int, not long.

Signed-off-by: Takuya Yoshikawa 
Signed-off-by: Marcelo Tosatti