linux-kernel - Re: [PATCH 5/5] fix kvm's use of _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130123000820.GA27204@amt.cnet>
Date:	Tue, 22 Jan 2013 22:08:20 -0200
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Gleb Natapov <gleb@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 5/5] fix kvm's use of __pa() on percpu areas

On Tue, Jan 22, 2013 at 01:24:35PM -0800, Dave Hansen wrote:
> 
> In short, it is illegal to call __pa() on an address holding
> a percpu variable.  This replaces those __pa() calls with
> slow_virt_to_phys().  All of the cases in this patch are
> in boot time (or CPU hotplug time at worst) code, so the
> slow pagetable walking in slow_virt_to_phys() is not expected
> to have a performance impact.
> 
> The times when this actually matters are pretty obscure
> (certain 32-bit NUMA systems), but it _does_ happen.  It is
> important to keep KVM guests working on these systems because
> the real hardware is getting harder and harder to find.
> 
> This bug manifested first by me seeing a plain hang at boot
> after this message:
> 
> 	CPU 0 irqstacks, hard=f3018000 soft=f301a000
> 
> or, sometimes, it would actually make it out to the console:
> 
> [    0.000000] BUG: unable to handle kernel paging request at ffffffff
> 
> I eventually traced it down to the KVM async pagefault code.
> This can be worked around by disabling that code either at
> compile-time, or on the kernel command-line.
> 
> The kvm async pagefault code was injecting page faults in
> to the guest which the guest misinterpreted because its
> "reason" was not being properly sent from the host.
> 
> The guest passes a physical address of an per-cpu async page
> fault structure via an MSR to the host.  Since __pa() is
> broken on percpu data, the physical address it sent was
> bascially bogus and the host went scribbling on random data.
> The guest never saw the real reason for the page fault (it
> was injected by the host), assumed that the kernel had taken
> a _real_ page fault, and panic()'d.  The behavior varied,
> though, depending on what got corrupted by the bad write.
> 
> Signed-off-by: Dave Hansen <dave@...ux.vnet.ibm.com>
> Acked-by: Rik van Riel <riel@...hat.com>
> ---
> 
>  linux-2.6.git-dave/arch/x86/kernel/kvm.c      |    9 +++++----
>  linux-2.6.git-dave/arch/x86/kernel/kvmclock.c |    4 ++--
>  2 files changed, 7 insertions(+), 6 deletions(-)
 

Reviewed-by: Marcelo Tosatti <mtosatti@...hat.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/