On Mon, Jul 14, 2014 at 7:21 PM, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote: > 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. I don't follow. The espfix64 stack is read-only by design. > > 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. How? This is a CPU misdesign we're talking about. --Andy -- 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