The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET
Date: Wed, 3 Aug 2016 19:14:29 +0200	[thread overview]
Message-ID: <20160803171429.GA2590@nazgul.tnic> (raw)
In-Reply-To: <CALCETrVodX3DkoaNygYDA+U5neBoCk51m+dNUkkY7p8-9Ces_A@mail.gmail.com>

On Wed, Aug 03, 2016 at 09:42:29AM -0700, Andy Lutomirski wrote:
> I would change "so" and "and" -- the CPU designers could have make
> SYSRET restore RF, but they chose not to.

I'm assuming the reasoning behind it was that you should be able to
break after SYSRET but then again, the kernel could've been left in
control of that bit and set it or clear it however it likes before
SYSRETing.

Oh well.

> Other than that substitution:
> 
> Acked-by: Andy Lutomirski <luto@kernel.org>

Thanks.

Here's v1.1:

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 3 Aug 2016 12:17:10 +0200
Subject: [PATCH -v1.1] x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET

Clarify why exactly RF cannot be restored properly by SYSRET to avoid
confusion.

No functionality change.

Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/entry/entry_64.S | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 8956eae04c25..b4b546bb23c3 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -288,11 +288,15 @@ return_from_SYSCALL_64:
 	jne	opportunistic_sysret_failed
 
 	/*
-	 * SYSRET can't restore RF.  SYSRET can restore TF, but unlike IRET,
-	 * restoring TF results in a trap from userspace immediately after
-	 * SYSRET.  This would cause an infinite loop whenever #DB happens
-	 * with register state that satisfies the opportunistic SYSRET
-	 * conditions.  For example, single-stepping this user code:
+	 * SYSCALL clears RF when it saves rFLAGS in R11 and SYSRET cannot
+	 * restore RF properly. If the slowpath sets it for whatever reason, we
+	 * need to restore it correctly.
+	 *
+	 * SYSRET can restore TF, but unlike IRET, restoring TF results in a
+	 * trap from userspace immediately after SYSRET.  This would cause an
+	 * infinite loop whenever #DB happens with register state that satisfies
+	 * the opportunistic SYSRET conditions.  For example, single-stepping
+	 * this user code:
 	 *
 	 *           movq	$stuck_here, %rcx
 	 *           pushfq
-- 
2.8.4


-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  reply	other threads:[~2016-08-03 17:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 10:19 [PATCH] x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET Borislav Petkov
2016-08-03 16:42 ` Andy Lutomirski
2016-08-03 17:14   ` Borislav Petkov [this message]
2016-08-03 17:24     ` Andy Lutomirski
2016-08-03 17:54       ` Borislav Petkov
2016-08-10 18:10     ` [tip:x86/urgent] " tip-bot for Borislav Petkov

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=20160803171429.GA2590@nazgul.tnic \
    --to=bp@alien8.de \
    --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