From: Andy Lutomirski <luto@kernel.org> To: Brian Gerst <brgerst@gmail.com> Cc: Andy Lutomirski <luto@kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Juergen Gross <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel <xen-devel@lists.xenproject.org> Subject: Re: [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup Date: Wed, 1 Jul 2020 11:39:40 -0700 [thread overview] Message-ID: <CALCETrVy-Q4K04wmEPe5VeU=at2BL4b-bSFkoSU-BPbTaTB2Yg@mail.gmail.com> (raw) In-Reply-To: <CAMzpN2iW4XD1Gsgq0ZeeH2eewLO+9Mk6eyk0LnbF-kP3v=smLg@mail.gmail.com> On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst <brgerst@gmail.com> wrote: > > On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski <luto@kernel.org> wrote: > > > > The SYSENTER frame setup was nonsense. It worked by accident > > because the normal code into which the Xen asm jumped > > (entry_SYSENTER_32/compat) threw away SP without touching the stack. > > entry_SYSENTER_compat was recently modified such that it relied on > > having a valid stack pointer, so now the Xen asm needs to invoke it > > with a valid stack. > > > > Fix it up like SYSCALL: use the Xen-provided frame and skip the bare > > metal prologue. > > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > Cc: Juergen Gross <jgross@suse.com> > > Cc: Stefano Stabellini <sstabellini@kernel.org> > > Cc: xen-devel@lists.xenproject.org > > Fixes: 1c3e5d3f60e2 ("x86/entry: Make entry_64_compat.S objtool clean") > > Signed-off-by: Andy Lutomirski <luto@kernel.org> > > --- > > arch/x86/entry/entry_64_compat.S | 1 + > > arch/x86/xen/xen-asm_64.S | 20 ++++++++++++++++---- > > 2 files changed, 17 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S > > index 7b9d8150f652..381a6de7de9c 100644 > > --- a/arch/x86/entry/entry_64_compat.S > > +++ b/arch/x86/entry/entry_64_compat.S > > @@ -79,6 +79,7 @@ SYM_CODE_START(entry_SYSENTER_compat) > > pushfq /* pt_regs->flags (except IF = 0) */ > > pushq $__USER32_CS /* pt_regs->cs */ > > pushq $0 /* pt_regs->ip = 0 (placeholder) */ > > +SYM_INNER_LABEL(entry_SYSENTER_compat_after_hwframe, SYM_L_GLOBAL) > > This skips over the section that truncates the syscall number to > 32-bits. The comments present some doubt that it is actually > necessary, but the Xen path shouldn't differ from native. That code > should be moved after this new label. Whoops. I thought I caught that myself, but apparently not. I'll fix it. > > -- > Brian Gerst
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@kernel.org> To: Brian Gerst <brgerst@gmail.com> Cc: Juergen Gross <jgross@suse.com>, Stefano Stabellini <sstabellini@kernel.org>, Andrew Cooper <andrew.cooper3@citrix.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@kernel.org>, xen-devel <xen-devel@lists.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com> Subject: Re: [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup Date: Wed, 1 Jul 2020 11:39:40 -0700 [thread overview] Message-ID: <CALCETrVy-Q4K04wmEPe5VeU=at2BL4b-bSFkoSU-BPbTaTB2Yg@mail.gmail.com> (raw) In-Reply-To: <CAMzpN2iW4XD1Gsgq0ZeeH2eewLO+9Mk6eyk0LnbF-kP3v=smLg@mail.gmail.com> On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst <brgerst@gmail.com> wrote: > > On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski <luto@kernel.org> wrote: > > > > The SYSENTER frame setup was nonsense. It worked by accident > > because the normal code into which the Xen asm jumped > > (entry_SYSENTER_32/compat) threw away SP without touching the stack. > > entry_SYSENTER_compat was recently modified such that it relied on > > having a valid stack pointer, so now the Xen asm needs to invoke it > > with a valid stack. > > > > Fix it up like SYSCALL: use the Xen-provided frame and skip the bare > > metal prologue. > > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > Cc: Juergen Gross <jgross@suse.com> > > Cc: Stefano Stabellini <sstabellini@kernel.org> > > Cc: xen-devel@lists.xenproject.org > > Fixes: 1c3e5d3f60e2 ("x86/entry: Make entry_64_compat.S objtool clean") > > Signed-off-by: Andy Lutomirski <luto@kernel.org> > > --- > > arch/x86/entry/entry_64_compat.S | 1 + > > arch/x86/xen/xen-asm_64.S | 20 ++++++++++++++++---- > > 2 files changed, 17 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S > > index 7b9d8150f652..381a6de7de9c 100644 > > --- a/arch/x86/entry/entry_64_compat.S > > +++ b/arch/x86/entry/entry_64_compat.S > > @@ -79,6 +79,7 @@ SYM_CODE_START(entry_SYSENTER_compat) > > pushfq /* pt_regs->flags (except IF = 0) */ > > pushq $__USER32_CS /* pt_regs->cs */ > > pushq $0 /* pt_regs->ip = 0 (placeholder) */ > > +SYM_INNER_LABEL(entry_SYSENTER_compat_after_hwframe, SYM_L_GLOBAL) > > This skips over the section that truncates the syscall number to > 32-bits. The comments present some doubt that it is actually > necessary, but the Xen path shouldn't differ from native. That code > should be moved after this new label. Whoops. I thought I caught that myself, but apparently not. I'll fix it. > > -- > Brian Gerst
next prev parent reply other threads:[~2020-07-01 18:39 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-26 17:21 [PATCH 0/6] x86/entry: Fixes Andy Lutomirski 2020-06-26 17:21 ` [PATCH 1/6] x86/entry: Assert that syscalls are on the right stack Andy Lutomirski 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski 2020-07-06 14:34 ` [PATCH] x86/entry: Mark check_user_regs() noinstr Peter Zijlstra 2020-06-26 17:21 ` [PATCH 2/6] x86/entry: Move SYSENTER's regs->sp and regs->flags fixups into C Andy Lutomirski 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski 2020-06-26 17:21 ` [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup Andy Lutomirski 2020-06-26 17:21 ` Andy Lutomirski 2020-06-28 2:47 ` Boris Ostrovsky 2020-06-28 2:47 ` Boris Ostrovsky 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski 2020-07-01 15:42 ` [PATCH 3/6] " Brian Gerst 2020-07-01 15:42 ` Brian Gerst 2020-07-01 18:39 ` Andy Lutomirski [this message] 2020-07-01 18:39 ` Andy Lutomirski 2020-07-02 12:54 ` Thomas Gleixner 2020-07-02 12:54 ` Thomas Gleixner 2020-06-26 17:21 ` [PATCH 4/6] selftests/x86/syscall_nt: Add more flag combinations Andy Lutomirski 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski 2020-06-26 17:21 ` [PATCH 5/6] selftests/x86/syscall_nt: Clear weird flags after each test Andy Lutomirski 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski 2020-06-26 17:21 ` [PATCH 6/6] selftests/x86: Consolidate and fix get/set_eflags() helpers Andy Lutomirski 2020-07-01 8:04 ` [tip: x86/urgent] " tip-bot2 for Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CALCETrVy-Q4K04wmEPe5VeU=at2BL4b-bSFkoSU-BPbTaTB2Yg@mail.gmail.com' \ --to=luto@kernel.org \ --cc=andrew.cooper3@citrix.com \ --cc=boris.ostrovsky@oracle.com \ --cc=brgerst@gmail.com \ --cc=jgross@suse.com \ --cc=linux-kernel@vger.kernel.org \ --cc=sstabellini@kernel.org \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.