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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Oct 2012 08:56:40 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	"H. Peter Anvin" <hpa@...or.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\!).

> From: H. Peter Anvin [mailto:hpa@...or.com]
> 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.

I agree the whole idea of paravirtualization is a hack, but it
is a hack to workaround some poor architectural design decisions
many years ago by Intel processor designers who should have known
better.  Go yell at them.

Worse, the rdtscp instruction was a poor design decision by
AMD processor designers to hack around tsc skew problems.
Go yell at them too.

And both Intel and AMD chose to perpetuate the problem
with a complicated VT/SVM implementation that will never
perform as well as native.  At least they tried ;-)
 
> 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.

Of course I know it doesn't exist.  I probably should have
noted that in my email.  But it should exist because else
subtle issues like this will get lost in the mist of time.
And I have no clue how to enforce it (though some BUILD_BUG_ON
might help).

Like so many other things in the kernel (and computing in general),
paravirtualization is a tradeoff of maintainability for kernel/software
developers vs significant performance improvement for (a large
number of) users.  That tradeoff is above my pay grade.  But
it does provide job security.
--
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/