On Wed, Aug 3, 2016 at 3:19 AM, Borislav Petkov <b...@alien8.de> wrote: > From: Borislav Petkov <b...@suse.de> > > Clarify why exactly RF cannot be restored properly by SYSRET to avoid > confusion. > > No functionality change. > > Signed-off-by: Borislav Petkov <b...@suse.de> > Cc: Andy Lutomirski <l...@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 <l...@kernel.org>
