On 07/14/2014 06:47 PM, H. Peter Anvin wrote:
On 07/14/2014 02:43 PM, Andrew Lutomirski wrote:
That patch is running through my build tests as we speak. I expect to
push it to tip:x86/urgent in about an hour.
I think that espfix64 is completely broken on Xen, regardless of the
pud vs pmd issue :( See:
http://lkml.kernel.org/g/CALCETrWG-dQL8ipJ8cO3wfbYKA=mAv3CS4-1JFwmBXF3pUbAwg@xxxxxxxxxxxxxx
This is exactly the problem that the patch is fixing:
paravirt_alloc_pte(&init_mm, __pa(stack_page) >> PAGE_SHIFT)
that we are removing is trying claim that stack_page is going to be the
PTE page (i.e. the last level). So the hypervisor will mark it read-only.
Any time someone writes to it the hypervisor presumes that this is a PTE
update and will perform various sanity checks before allowing the update
to succeed. Obviously writing random data (from PTE format perspective)
will not be allowed and a fault will be returned to the guest.
You can easily simulate this by, for example, allocating stack_page with
__GFP_ZERO and writing -1 to espfix_waddr at the end of init_espfix_ap().
And it is also completely unclear to me if it is actually necessary.
Again, I would like to know how the Xen IRET pvop actually handles a
16-bit stack segment. If it restores all of RSP then espfix isn't
necessary.
Last time I looked at this I thought it was not necessary since the iret
handler in the hypervisor copies saved RSP. I may be wrong though.
-boris
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html