Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 3 Aug 2016 09:42:29 -0700 | Subject | Re: [PATCH] x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET |
| |
On Wed, Aug 3, 2016 at 3:19 AM, Borislav Petkov <bp@alien8.de> wrote: > From: Borislav Petkov <bp@suse.de> > > Clarify why exactly RF cannot be restored properly by SYSRET to avoid > confusion. > > No functionality change. > > Signed-off-by: Borislav Petkov <bp@suse.de> > Cc: 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..80ad6d0fe38b 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 so SYSRET cannot
I would change "so" and "and" -- the CPU designers could have make SYSRET restore RF, but they chose not to.
Other than that substitution:
Acked-by: Andy Lutomirski <luto@kernel.org>
| |