linux-kernel - Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).

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: <50802030.8070107@zytor.com>
Date:	Thu, 18 Oct 2012 08:28:48 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Konrad Wilk <konrad.wilk@...cle.com>, linux-acpi@...r.kernel.org,
	x86@...nel.org, xen-devel@...ts.xensource.com,
	linux-kernel@...r.kernel.org, lenb@...nel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).

On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
>
> It's a bit more complicated than that.  The problem is that if
> any patch is ever submitted to the kernel that uses the rdtscp
> instruction *in kernel space* in some clever way, the resultant
> kernel may not behave as expected (depending on how the instruction
> is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> the possibility of data corruption.
>
> I don't know how one would implement it, but it's like a
> BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> (one that never gets invoked by vdso code), that prints:
>
> "WARNING: Please do not use this instruction in the kernel
> without notifying the Xen maintainer as there is a possibility
> it may behave unpredictably in some Xen environments.
> See Documentation/.../xen_pv_limitations for detail."
>
> The other virtualization-unsafe instructions may have similar
> problems.
>

Good frakking God.  This is the sort of things that makes me think that 
Xen PV should just be thrown out of the kernel once and for all.

Do you notice that the document you just claimed doesn't even exist at 
this point, never mind being somehow enforced?  In other word, there is 
ABSOLUTELY NO WAY a mainline kernel developer can have any idea what 
amount of violence Xen does to the architecture that it is parasiting on.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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