linux-kernel - Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD Trinity systems

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: <4FC762F8.902@amd.com>
Date:	Thu, 31 May 2012 14:24:24 +0200
From:	Andre Przywara <andre.przywara@....com>
To:	Konrad Rzeszutek Wilk <konrad@...nok.org>
CC:	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Jacob Shin <jacob.shin@....com>, <jeremy@...p.org>,
	<xen-devel@...ts.xensource.com>, <linux-kernel@...r.kernel.org>,
	Jan Beulich <JBeulich@...e.com>, <mingo@...e.hu>,
	<tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD Trinity
 systems

On 05/31/2012 12:33 AM, Konrad Rzeszutek Wilk wrote:
>>> Now, someone probably needs to paravirt the *safe_regs variants in case
>>> something else decides to use them. I don't know what to do here, do I
>>> want more paravirt code in there? No. I guess if this is done carefully
>>> and cleanly, then it should be ok but it can't be done like that - it
>>> needs to adhere to the current pv_cpu_ops thing which is already there.
>
> Using the native variant seems the right thing to do.
>>>
>>
>> I thought I was being told that Xen would trap and emulate the
>> rdmsr/wrmsr instructions.  I guess they don't want to do that for the
>
> It does.
>> handful of performance-sensitive MSRs there are, but those don't use the
>> *_regs variants.
>
> The underlaying issue (as I understand) was that .rdmsr_regs
> (and the corresponding write) was NULL and that caused the crash.
> This tiny patch should do it:
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 75f33b2..e74df95 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
>   	.wbinvd = native_wbinvd,
>
>   	.read_msr = native_read_msr_safe,
> +	.rdmsr_regs = native_rdmsr_safe_regs,
>   	.write_msr = xen_write_msr_safe,
> +	.wrmsr_regs = native_wrmsr_safe_regs,
> +
>   	.read_tsc = native_read_tsc,
>   	.read_pmc = native_read_pmc,
>
>

Acked-by: Andre Przywara <andre.przywara@....com>

This works on the test machine.

Though I'd still like to have my original patch applied, because it 
makes the thing a bit cleaner.

And I made a patch to remove the {rd,wr}msr_regs hooks from paravirt_ops 
completely. Shall I send it out or do you want to make this part of 
larger patch series to clean up pvops?

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--
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/