From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932805AbcHCROx (ORCPT ); Wed, 3 Aug 2016 13:14:53 -0400 Received: from mail.skyhub.de ([78.46.96.112]:39751 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932475AbcHCROv (ORCPT ); Wed, 3 Aug 2016 13:14:51 -0400 Date: Wed, 3 Aug 2016 19:14:29 +0200 From: Borislav Petkov To: Andy Lutomirski Cc: X86 ML , LKML Subject: Re: [PATCH] x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET Message-ID: <20160803171429.GA2590@nazgul.tnic> References: <20160803101924.27247-1-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Thanks. Here's v1.1: --- From: Borislav Petkov 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 Acked-by: Andy Lutomirski --- 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. --