From: Ingo Molnar <mingo@kernel.org>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/asm/entry/64: better check for canonical address
Date: Fri, 27 Mar 2015 09:11:42 +0100 [thread overview]
Message-ID: <20150327081141.GA9526@gmail.com> (raw)
In-Reply-To: <1427373731-13056-1-git-send-email-dvlasenk@redhat.com>
* Denys Vlasenko <dvlasenk@redhat.com> wrote:
> This change makes the check exact (no more false positives
> on kernel addresses).
>
> It isn't really important to be fully correct here -
> almost all addresses we'll ever see will be userspace ones,
> but OTOH it looks to be cheap enough:
> the new code uses two more ALU ops but preserves %rcx,
> allowing to not reload it from pt_regs->cx again.
> On disassembly level, the changes are:
>
> cmp %rcx,0x80(%rsp) -> mov 0x80(%rsp),%r11; cmp %rcx,%r11
> shr $0x2f,%rcx -> shl $0x10,%rcx; sar $0x10,%rcx; cmp %rcx,%r11
> mov 0x58(%rsp),%rcx -> (eliminated)
>
> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
> CC: Borislav Petkov <bp@alien8.de>
> CC: x86@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>
> Andy, I'd undecided myself on the merits of doing this.
> If you like it, feel free to take it in your tree.
> I trimmed CC list to not bother too many people with this trivial
> and quite possibly "useless churn"-class change.
>
> arch/x86/kernel/entry_64.S | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index bf9afad..a36d04d 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -688,26 +688,27 @@ retint_swapgs: /* return to user-space */
> * a completely clean 64-bit userspace context.
> */
> movq RCX(%rsp),%rcx
> - cmpq %rcx,RIP(%rsp) /* RCX == RIP */
> + movq RIP(%rsp),%r11
> + cmpq %rcx,%r11 /* RCX == RIP */
> jne opportunistic_sysret_failed
Btw., in the normal syscall entry path, RIP(%rsp) == RCX(%rsp),
because we set up pt_regs like that - and at this point RIP/RCX is
guaranteed to be canonical, right?
So if there's a mismatch generated, it's the kernel's doing.
Why don't we detect those cases where a new return address is created
(ptrace, exec, etc.), check for canonicalness and add a TIF flag for
it (and add it to the work mask) and execute the IRET from the slow
path?
We already have a work-mask branch.
That would allow the removal of all these checks and canonization from
the fast return path! We could go straight to the SYSRET...
The frequency of exec() and ptrace() is 2-3 orders of magnitude lower
than the frequency of system calls, so this would be well worth it.
Am I missing anything?
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-27 8:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 12:42 [PATCH] x86/asm/entry/64: better check for canonical address Denys Vlasenko
2015-03-26 18:45 ` Andy Lutomirski
2015-03-27 8:57 ` Borislav Petkov
2015-03-30 14:27 ` Denys Vlasenko
2015-03-30 14:30 ` Andy Lutomirski
2015-03-30 14:45 ` Andy Lutomirski
2015-03-27 8:11 ` Ingo Molnar [this message]
2015-03-27 10:45 ` Denys Vlasenko
2015-03-27 11:17 ` Ingo Molnar
2015-03-27 11:28 ` Brian Gerst
2015-03-27 11:34 ` Ingo Molnar
2015-03-27 12:14 ` Denys Vlasenko
2015-03-27 12:16 ` Ingo Molnar
2015-03-27 12:31 ` Denys Vlasenko
2015-03-28 9:11 ` Ingo Molnar
2015-03-29 19:36 ` Denys Vlasenko
2015-03-29 21:12 ` Andy Lutomirski
2015-03-29 21:46 ` Denys Vlasenko
2015-03-31 16:43 ` Ingo Molnar
2015-03-31 17:08 ` Andy Lutomirski
2015-03-31 17:31 ` Denys Vlasenko
2015-03-27 11:27 ` Brian Gerst
2015-03-27 11:31 ` Ingo Molnar
2015-03-27 21:37 ` Andy Lutomirski
2015-04-02 17:37 ` Denys Vlasenko
2015-04-02 18:10 ` Ingo Molnar
2015-04-21 16:27 Denys Vlasenko
2015-04-21 18:08 ` Andy Lutomirski
2015-04-23 15:10 ` Borislav Petkov
2015-04-23 15:41 ` Andy Lutomirski
2015-04-23 15:49 ` Borislav Petkov
2015-04-23 15:52 ` 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=20150327081141.GA9526@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=x86@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).