The current alias ioctl allows for the creation of
an alias covering a gpa that already exists. It is invalid,
because the gpa space needs to be uniquely mapped. So, if
there's a memory slot covering gpa range 0x123000 to 0x124000,
and we create an alias from any gpa within that range to a different
target, we create an essential ambiguity that brings no value at
the cost of a lot of confusion. Right now this confusion
manifests itself as a BUG() triggered in the rmaps code path.
Signed-off-by: Glauber Costa <[email protected]>
---
arch/x86/kvm/x86.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7a2aeba..c3b5770 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1591,6 +1591,8 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
{
int r, n;
struct kvm_mem_alias *p;
+ gfn_t base_gfn;
+ unsigned long npages;
r = -EINVAL;
/* General sanity checks */
@@ -1607,12 +1609,18 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
< alias->target_phys_addr)
goto out;
+ base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
+ npages = alias->memory_size >> PAGE_SHIFT;
+
+ if (gfn_to_memslot(kvm, base_gfn) || gfn_to_memslot(kvm, base_gfn + npages))
+ goto out;
+
down_write(&kvm->slots_lock);
spin_lock(&kvm->mmu_lock);
p = &kvm->arch.aliases[alias->slot];
- p->base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
- p->npages = alias->memory_size >> PAGE_SHIFT;
+ p->base_gfn = base_gfn;
+ p->npages = npages;
p->target_gfn = alias->target_phys_addr >> PAGE_SHIFT;
for (n = KVM_ALIAS_SLOTS; n > 0; --n)
--
1.5.6.5
Glauber Costa wrote:
> The current alias ioctl allows for the creation of
> an alias covering a gpa that already exists. It is invalid,
> because the gpa space needs to be uniquely mapped. So, if
> there's a memory slot covering gpa range 0x123000 to 0x124000,
> and we create an alias from any gpa within that range to a different
> target, we create an essential ambiguity that brings no value at
> the cost of a lot of confusion. Right now this confusion
> manifests itself as a BUG() triggered in the rmaps code path.
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 7a2aeba..c3b5770 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1591,6 +1591,8 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
> {
> int r, n;
> struct kvm_mem_alias *p;
> + gfn_t base_gfn;
> + unsigned long npages;
>
> r = -EINVAL;
> /* General sanity checks */
> @@ -1607,12 +1609,18 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
> < alias->target_phys_addr)
> goto out;
>
> + base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
> + npages = alias->memory_size >> PAGE_SHIFT;
> +
> + if (gfn_to_memslot(kvm, base_gfn) || gfn_to_memslot(kvm, base_gfn + npages))
> + goto out;
> +
>
This says nothing about base_gfn + 17. Moreover, we don't care if
base+gfn +npages is mapped - it's outside the half-closed alias range.
Further, a clever attacker would first establish the alias, then the
memslot, bypassing the checks. I suggest (a) extracting a function to
check for range overlap from the memslot code, (b) extending it to check
for both memslots and aliases, and (c) using it everywhere.
--
error compiling committee.c: too many arguments to function