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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 May 2012 10:50:05 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Jacob Shin <jacob.shin@....com>
Cc:	Andre Przywara <andre.przywara@....com>,
	Jan Beulich <JBeulich@...e.com>, mingo@...e.hu,
	jeremy@...p.org, tglx@...utronix.de, xen-devel@...ts.xensource.com,
	linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems

On Wed, May 30, 2012 at 09:48:51AM -0500, Jacob Shin wrote:
> On Wed, May 30, 2012 at 04:02:48PM +0200, Andre Przywara wrote:
> > On 05/30/2012 03:33 PM, Jan Beulich wrote:
> > >>>>On 30.05.12 at 15:10, Andre Przywara<andre.przywara@....com>  wrote:
> > >>Because we are behind a family check before tweaking the topology
> > >>bit, we can use the standard rd/wrmsr variants for the CPUID feature
> > >>register.
> > >>This fixes a crash when using the kernel as a Xen Dom0 on affected
> > >>Trinity systems. The wrmsrl_amd_safe is not properly paravirtualized
> > >>yet (this will be fixed in another patch).
> > >
> > >I'm not following: If the AMD variants (putting a special value into
> > >%edi) can be freely replaced by the non-AMD variants, why did
> > >the AMD special ones get used in the first place?
> > 
> > Older CPUs (K8) needed the AMD variants, starting with family 10h we
> > can use the normal versions.
> > 
> > >Further, I can't see how checking_wrmsrl() is being paravirtualized
> > >any better than wrmsrl_amd_safe() - both have nothing but an
> > >exception handling fixup attached to the wrmsr invocation. Care
> > >to point out what actual crash it is that was seen?
> > 
> > AFAIK, the difference is between the "l" and the regs version for
> > rd/wrmsr. We have a patch already here to fix this. Will send it out
> > soon. Jacob, can you comment on this?
> 
> Right, the checking_wrmsrl turns into wrmsr_safe which is paravirtualized
> but the rdmsrl_amd_safe which turns into rdmsr_regs is not paravirtualized
> by enlighten.

So would a patch to implements the rdmsr_regs fix this crash?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ