Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755212AbbGZXFq (ORCPT ); Sun, 26 Jul 2015 19:05:46 -0400 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]:47460 "EHLO ppsw-50.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754448AbbGZXFp (ORCPT ); Sun, 26 Jul 2015 19:05:45 -0400 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: Getting rid of invalid SYSCALL RSP under Xen? To: Andy Lutomirski References: <55B53636.80304@citrix.com> Cc: X86 ML , Boris Ostrovsky , "linux-kernel@vger.kernel.org" , Borislav Petkov , Steven Rostedt , "xen-devel@lists.xen.org" From: Andrew Cooper X-Enigmail-Draft-Status: N1110 Message-ID: <55B567C1.3050709@citrix.com> Date: Mon, 27 Jul 2015 00:05:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2681 Lines: 67 On 26/07/2015 23:08, Andy Lutomirski wrote: > >>> If so, can we just >>> enter later on: >>> >>> pushq %r11 /* pt_regs->flags */ >>> pushq $__USER_CS /* pt_regs->cs */ >>> pushq %rcx /* pt_regs->ip */ >>> >>> <-- Xen enters here >>> >>> pushq %rax /* pt_regs->orig_ax */ >>> pushq %rdi /* pt_regs->di */ >>> pushq %rsi /* pt_regs->si */ >>> pushq %rdx /* pt_regs->dx */ >> This looks plausible, and indeed preferable to the current doublestep >> with undo_xen_syscall. >> >> One slight complication is that xen_enable_syscall() will want to >> special case register_callback() to not set CALLBACKF_mask_events, as >> the entry point is now after re-enabling interrupts. > I wouldn't do that. Let's just move the ENABLE_INTERRUPTS a few > instructions later even on native -- I want to do that anyway. That would also work. > >>> For SYSRET, I think the way to go is to force Xen to always use the >>> syscall slow path. Instead, Xen could hook into >>> syscall_return_via_sysret or even right before the opportunistic >>> sysret stuff. Then we could remove the USERGS_SYSRET hooks entirely. >>> >>> Would this work? >> None of the opportunistic sysret stuff makes sense under Xen. The path >> will inevitably end up in xen_iret making a hypercall. Short circuiting >> all of this seems like a good idea, especially if it allows for the >> removal of the UERGS_SYSRET. > Doesn't Xen decide what to do based on VGCF_IN_SYSCALL? Maybe Xen > should have its own opportunistic VGCF_IN_SYSCALL logic. VGCF_in_syscall affects whether the extra r11/rcx get restored or not, as the hypercall itself is implemented using syscall. As the extra r11/rcx (and rax for that matter) are unconditionally saved in the hypercall stub, I can't see anything Linux could usefully do, opportunistically speaking. > > Hmm, maybe some of this would be easier to think about if, rather than > having a paravirt op, we could have: > > ALTERNATIVE "", "jmp xen_pop_things_and_iret", X86_FEATURE_XEN > > Or just IF_XEN("jmp ..."); > > As a practical matter, x86_64 has native and Xen -- I don't think > there's any other paravirt platform that needs the asm hooks. It would certainly seem so. A careful use of IF_XEN() or two would make the code far clearer to read, and to drop the hooks. ~Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/